Rédiger un cahier des charges pour un prestataire IA

Un cahier des charges IA mal écrit ne se paie pas au moment de la signature : il se paie six mois plus tard, quand le prestataire livre un système qui répond correctement dans huit cas sur dix et que personne, dans la salle, n'est capable de dire si c'est conforme ou non. Le document ne prévoyait pas de seuil. Il n'y a donc rien à opposer.

C'est la différence de fond avec un projet logiciel classique. Une facture est éditée ou elle ne l'est pas. Un résumé de compte rendu, lui, est bon, moyen ou passable, et la frontière entre les trois dépend de qui lit. Spécifier un projet IA, c'est essentiellement transformer cette appréciation subjective en quelque chose qui se mesure devant témoin.

Cet article donne une trame complète, testée sur des consultations de taille PME : les sept sections à écrire, ce qu'on met dans chacune, et le détail des critères d'acceptation, qui représentent à eux seuls la moitié de la valeur du document. Il suppose que le cadrage amont est déjà fait : si ce n'est pas le cas, commencez par la méthode de cadrage d'un projet IA, un cahier des charges écrit sur un besoin flou ne produit que des devis flous.

Ce qu'un cahier des charges IA doit contenir de plus qu'un cahier des charges logiciel

Quatre éléments distinguent une consultation IA d'une consultation applicative ordinaire. Ils expliquent pourquoi une trame générique ne suffit pas.

• Le résultat n'est pas déterministe. Deux exécutions sur la même entrée peuvent produire deux sorties différentes. La recette doit donc porter sur un échantillon, pas sur un cas.
• La performance dépend de vos données autant que du prestataire. Si votre documentation est incomplète, aucun assistant ne répondra bien. Le cahier des charges doit dire ce que vous fournissez et dans quel état.
• Le système se dégrade sans que personne n'y touche. Un modèle change de version, un fournisseur modifie son interface, vos processus évoluent. Il faut prévoir qui surveille et qui répare.
• Le cadre réglementaire s'applique au système, pas au code. Selon l'usage, le règlement européen sur l'intelligence artificielle impose des obligations de documentation et de supervision humaine. Elles se contractualisent.

Un cahier des charges qui ignore ces quatre points produit mécaniquement des réponses non comparables : chaque prestataire comblera les trous à sa façon, et généralement dans le sens qui l'arrange.

La trame en sept sections

Sept sections suffisent. Au delà, le document devient illisible et personne ne le relit à la recette, ce qui annule son intérêt. Comptez quinze à vingt-cinq pages pour un projet de 30 000 à 80 000 euros.

1. Le problème, pas la solution. Décrivez la situation actuelle avec des volumes et des durées : « le service administratif traite 340 demandes par mois, chacune demande en moyenne 12 minutes de recherche documentaire ». N'écrivez pas « nous voulons un agent conversationnel ». Vous achetez un résultat, laissez le prestataire proposer le moyen.
2. Le périmètre, et surtout le hors périmètre. La liste de ce qui n'est pas dans le projet vaut plus cher que la liste de ce qui y est. Trois lignes de hors périmètre évitent trois avenants.
3. Les données fournies. Nature, volume, format, qualité constatée, qui les prépare, sous quel délai.
4. Les contraintes. Hébergement, localisation des traitements, sous traitants autorisés, systèmes à intégrer, contraintes d'authentification.
5. Les critères d'acceptation. Le cœur du document, détaillé plus bas.
6. Le fonctionnement après la livraison. Supervision, correction, coût de fonctionnement, montée de version du modèle.
7. Propriété, réversibilité et attendus de la réponse. Ce qui vous appartient, ce que vous récupérez si vous partez, et le format de réponse imposé pour pouvoir comparer.

Les critères d'acceptation, seul moyen de trancher un désaccord

Un critère d'acceptation utile tient en une phrase et contient toujours quatre choses : une mesure, un seuil, un jeu de test, et une personne qui juge. Il s'écrit avant le début du projet, jamais pendant la recette.

La méthode la plus simple consiste à constituer un jeu de 50 à 150 cas représentatifs, tirés de votre historique réel, avec la bonne réponse attendue. Ce jeu est annexé au cahier des charges. Le prestataire le connaît, ce qui n'est pas un problème : ce que vous mesurez, c'est la capacité du système à traiter cette classe de cas. Prévoyez en revanche un second jeu, tenu à l'écart, pour la recette finale. Notre article sur l'évaluation des réponses d'une IA par jeu de tests détaille la construction de ces échantillons.

Deux précautions pratiques. D'abord, prévoyez un seuil de non régression : le système doit rester au dessus du seuil trois mois après la mise en service, et pas seulement le jour de la recette. Ensuite, décrivez ce qui se passe si le seuil n'est pas atteint : correction sous quel délai, retenue de paiement, ou révision du périmètre. Un critère sans conséquence contractuelle est un vœu.

Fixer un seuil réaliste

Un seuil trop haut fait fuir les prestataires sérieux et attire ceux qui promettent tout. Pour un assistant de recherche documentaire interne, 85 à 92 % de réponses jugées correctes est un ordre de grandeur atteignable. Pour une extraction de champs sur des documents structurés, on monte à 97 %. Pour une génération de texte destinée à un client final sans relecture, aucun seuil ne devrait vous rassurer : prévoyez plutôt une validation humaine.

Données fournies, propriété et réversibilité

La section données est celle qui protège le prestataire, ce qui est aussi votre intérêt : sans elle, tout retard de qualité vous sera imputé, et à raison. Écrivez noir sur blanc le volume, la période couverte, le format, le taux de champs vides constaté et la date à laquelle vous livrez. Prévoyez une clause simple : si les données livrées s'écartent significativement de cette description, le planning et le prix sont renégociés.

Sur la propriété, quatre objets se distinguent et se traitent séparément :

• Vos données sources et vos données produites. Elles restent votre propriété, sans exception, et ne peuvent servir à entraîner un modèle sans accord écrit distinct.
• Les développements spécifiques. Prévoyez une cession de droits explicite, ou une licence perpétuelle. Le silence du contrat joue contre vous.
• Les invites et les configurations. Souvent oubliées, ce sont pourtant elles qui portent le savoir faire accumulé. Exigez leur remise en clair.
• Les briques réutilisables du prestataire. Il est normal qu'elles lui restent. Exigez alors une licence d'usage sans limite de durée et le droit de les faire maintenir par un tiers.

La réversibilité se teste, elle ne se déclare pas. Ajoutez un critère d'acceptation dédié : à la fin du projet, le prestataire fournit une archive complète (code, configurations, invites, jeux de test, documentation) et vous vérifiez qu'un tiers peut la reprendre. C'est aussi ce point qui vous permettra de changer d'interlocuteur sans repartir de zéro, sujet développé dans notre guide pour choisir un prestataire IA dans la région lyonnaise.

Comment imposer un format de réponse comparable

Un appel d'offres en intelligence artificielle produit souvent trois réponses impossibles à mettre côte à côte : l'une chiffre en jours, l'autre au forfait, la troisième propose un abonnement. Imposez une structure de réponse, c'est votre droit et cela vous fait gagner des semaines.

• Un chiffrage séparé en trois blocs : conception, réalisation, fonctionnement annuel.
• Le coût de fonctionnement estimé sur douze mois, hypothèses de volume explicitées, coûts d'appel aux modèles inclus.
• La liste nominative des sous traitants et des services tiers utilisés, avec la localisation des traitements.
• Deux références comparables, avec un contact joignable.
• Le nom et le taux d'occupation des personnes réellement affectées.

Sur le coût de fonctionnement, méfiez vous des réponses à zéro euro : elles signifient que le prestataire n'a pas fait le calcul, ou qu'il le reportera sur vous en facture directe. Notre article sur le coût réel d'un projet d'IA générative donne les ordres de grandeur permettant de repérer une estimation fantaisiste.

Les erreurs qui coûtent le plus cher

Trois erreurs reviennent dans presque toutes les consultations que nous avons pu lire.

1. Décrire une solution technique au lieu d'un besoin. Vous vous privez des propositions les plus efficaces, et vous devenez responsable du choix d'architecture. En cas d'échec, le prestataire aura livré ce que vous avez demandé.
2. Oublier la charge interne. Un projet IA réclame du temps métier : constitution du jeu de test, relecture, arbitrages. Comptez 15 à 25 jours de vos équipes sur un projet de trois mois, et inscrivez le dans le document.
3. Laisser la recette au ressenti. Sans jeu de test annexé, la fin de projet se joue sur une démonstration bien préparée, et le désaccord surgit en production, quand le paiement est déjà fait.

Par où commencer cette semaine

Un cahier des charges IA utile se construit dans cet ordre : écrivez d'abord le problème avec des chiffres, puis constituez le jeu de test avec les personnes qui font le travail aujourd'hui, puis seulement rédigez le reste. Le jeu de test écrit tout seul les trois quarts du périmètre, parce qu'il oblige à décider ce qui est dans le champ et ce qui n'y est pas.

Comptez deux à trois semaines pour un premier document exploitable, dont une bonne moitié consacrée à l'échantillon de cas. C'est du temps rentable : c'est le seul investissement qui vous donne, en fin de projet, un argument mesurable à opposer plutôt qu'une impression à défendre. Et lorsque vous consultez plusieurs prestataires, c'est ce même document qui rend les propositions comparables ligne à ligne au lieu de vous laisser arbitrer sur la qualité des diapositives.