Un cahier des charges IA sert à décider. Il décrit le processus de référence, les données disponibles, les critères de qualité, les interfaces, le contrôle humain, le coût complet, les responsables et la décision de poursuite.
À quoi sert ce document
Un cahier des charges IA ne liste pas des fonctionnalités. Il fixe les critères qui permettront de dire oui ou non à un prototype, posés avant de l'avoir vu. Sans ce filtre, la démonstration se juge à l'impression qu'elle laisse, et l'impression est presque toujours bonne.
Les huit points qui suivent, nous les documentons avant d'écrire la moindre ligne de code. Ils tiennent en quelques pages. Un point resté vide n'est pas un oubli de rédaction : c'est une question ouverte qui se paiera plus tard, au moment de décider.
Un cahier des charges qui ne permet pas de refuser le prototype ne sert à rien.
1. Le processus de référence
Décrivez le processus tel qu'il tourne aujourd'hui : ses étapes, ses acteurs, le temps passé à chacune. Pour un traitement de factures, cela veut dire chronométrer séparément la réception, la saisie, le rapprochement et la validation. Chiffrez ce temps avant de commencer, pas après : un gain ne se mesure que par rapport à un point de départ connu, et ce point de départ ne s'établit plus honnêtement une fois la solution en place.
Précisez aussi le volume : combien de fois par an ce processus s'exécute, et par combien de personnes. Un gain unitaire spectaculaire sur un processus lancé douze fois par an ne justifie pas un projet.
2. Les données disponibles
Listez ce qu'il faut : emplacement réel, format, volume, historique. Une base qui existe mais dont l'accès demande trois mois de validation juridique n'est pas disponible au sens de ce document, elle est simplement hypothétique.
Qui autorise l'accès ? Sous quelles conditions ? Les données peuvent-elles sortir du système d'information ? Ces réponses déterminent une partie de l'architecture : mieux vaut les avoir avant de la choisir.
3. Les critères de qualité
Écrivez ce qui sera mesuré, comment, et à partir de quel seuil le résultat devient acceptable. Un bon critère se vérifie par quelqu'un qui n'a pas participé au développement, un contrôleur qualité extérieur à l'équipe projet, par exemple.
Prévoyez deux jeux de données distincts, un pour le développement, un pour l'évaluation, ce dernier n'intervenant jamais pendant la construction. Sans cette séparation, la mesure décrit la capacité du système à retrouver ce qu'on lui a montré, pas sa capacité à traiter un cas nouveau.
4. Les interfaces
Où le résultat sera-t-il consulté, et par qui ? Un système qui produit une bonne réponse dans un outil que personne n'ouvre ne change rien au processus de référence, qu'il s'agisse d'un tableau de bord isolé ou d'un courriel que personne ne lit.
Documentez les intégrations attendues avec l'existant : quel logiciel appelle quoi, dans quel sens, avec quelle authentification. C'est souvent là que se cache la plus grande part de la charge de travail, et presque toujours la partie sous-estimée au chiffrage.
5. Le contrôle humain
Définissez le niveau de contrôle en fonction du risque, pas du confort. Trois régimes suffisent la plupart du temps : validation systématique avant usage, contrôle par échantillon, ou fonctionnement autonome avec alerte sur les cas incertains. Pour une réponse à appel d'offres, la validation systématique s'impose souvent ; pour un tri de courrier entrant, l'échantillonnage peut suffire.
Qui exerce ce contrôle ? Combien de temps y consacre-t-il ? Que fait-il quand il n'est pas d'accord avec le système ? Un gain de temps calculé sans compter la relecture n'est pas un gain de temps.
6. Le coût complet
Additionnez mise en œuvre et exploitation. L'exploitation comprend l'infrastructure, les appels aux modèles le cas échéant, la surveillance, les mises à jour et le temps interne consacré au contrôle.
Exprimez le coût d'exploitation par unité traitée, pas seulement en total annuel : c'est cette valeur qui indique ce qui se passe si le volume double, et c'est la question qu'on se pose toujours trop tard.
7. Les responsables
Nommez une personne pour les données, une pour le métier, une pour l'exploitation. Trois noms, pas trois directions.
Précisez qui tranche en cas de désaccord sur la qualité d'un résultat. La question paraît théorique au cadrage ; elle devient la plus concrète de toutes dès la première mise en service.
8. La décision de poursuite
Fixez ce qui déclenchera la suite et ce qui déclenchera l'arrêt, avec les seuils correspondants. Prévoyez explicitement le cas où le prototype fonctionne mais ne justifie pas la mise en production : c'est un résultat, pas un échec, et il vaut mieux l'avoir nommé à l'avance.
Datez la décision. Un point d'arrêt sans date se transforme en prolongation par défaut.
Comment l'utiliser
Ces huit points se remplissent en un à deux ateliers, avec les personnes qui exécutent le processus, pas seulement celles qui le pilotent. Le document obtenu sert de référence commune pendant toute la durée du projet et de base à l'évaluation à chaque étape.
Pour le passer en revue sur un processus précis, écrivez-nous à hello@neurixis.ai.
