Un cahier des charges projet IA sert d’abord à décider si une livraison peut être acceptée. Écrivez une chaîne d’acceptation en cinq portes : Source, Attendu, Test, Validation humaine, Décision. Avant la construction, chaque cas fixe un résultat attendu. Après la construction, le même cas reçoit un résultat constaté, une preuve et une décision humaine : déployer, réviser ou arrêter. Le document ne prédit donc pas toute l’implémentation. Il rend visibles la frontière du projet, les écarts et la personne qui tranche. Mais une liste de modèles, d’agents ou de connecteurs ne remplit pas ce rôle.
Comment la chaîne d’acceptation transforme-t-elle une demande en décision ?
La chaîne d’acceptation relie chaque source autorisée à une décision assumée. Mais ses cinq portes ne décrivent pas la réalisation technique. Elles décrivent ce que le responsable métier doit pouvoir inspecter.
- Source. Quelle entrée est permise ? Quel document ou registre fait autorité ? Que se passe-t-il si la source manque ou se contredit ?
- Attendu. Quel résultat précis, quel refus ou quel arrêt doit produire ce cas ?
- Test. Quelle entrée fixe permettra de comparer le résultat attendu au résultat constaté ?
- Validation humaine. Qui examine la sortie, la preuve et l’écart ?
- Décision. Les preuves permettent-elles de déployer dans la frontière testée, faut-il réviser, ou faut-il arrêter ?
Une demande vague dit : « routez les demandes internes avec l’IA ». Donc la chaîne oblige à montrer l’entrée autorisée, le brouillon attendu, le cas testé, le constat après construction et le nom de la personne qui accepte ou refuse.
L’outil ne constitue pas la preuve. Le nom d’un modèle, d’une plateforme ou d’un agent renseigne sur un choix de réalisation. Mais la preuve d’acceptation est un résultat inspectable relié à une entrée, à une source et à une décision.
Le NIST AI Risk Management Framework est un cadre volontaire destiné à intégrer des considérations de confiance dans la conception, le développement, l’utilisation et l’évaluation des systèmes d’IA. Son noyau emploie les fonctions Govern, Map, Measure et Manage. Le Playbook du NIST propose des actions volontaires, sans former une checklist ni une séquence obligatoire. Mais la chaîne présentée ici est un modèle éditorial distinct.
Quelles sont les sept parties du cahier des charges à réunir dans une fiche ?
Copiez cette fiche et répondez sous chaque titre avec des objets vérifiables. Inscrivez une frontière, un schéma de sortie, un cas de test ou un nom de responsable. Mais retirez les adjectifs tels que « fluide » ou « intelligent » lorsqu’ils ne désignent rien à inspecter.
- Problème et situation initiale observable. Décrivez le problème métier sans imposer la solution. Notez l’observation de départ et la manière de la reproduire lors de la revue.
- Workflow inclus et exclusions explicites. Écrivez l’événement de départ, le point de fin, les personnes ou systèmes concernés et les actions exclues.
- Entrées autorisées et autorité des sources. Nommez les formats et dépôts permis, la source qui prévaut et le comportement attendu si elle manque ou se contredit.
- Format de sortie et critères d’acceptation. Fixez les champs, la structure, la langue, les références requises, le contenu interdit et les motifs de rejet.
- Jeu de tests. Préparez les entrées de référence et écrivez leur résultat attendu avant la construction.
- Validation humaine, échec, arrêt et preuves. Nommez le validateur, les cas d’arrêt et les versions d’entrée, de sortie, de source et de décision à conserver.
- Responsable et décision de revue. Nommez la personne qui maintient le document, donnez une date à la revue et consignez la décision : déployer, réviser ou arrêter.
France Num recommande, pour les agents conversationnels et assistants virtuels, de formaliser les objectifs, les rôles et les règles, de tester avant le déploiement, de prévoir une supervision humaine pour les tâches sensibles, ainsi que la traçabilité et la maintenance (France Num).
Pourquoi le test de référence précède-t-il le test d’acceptation ?
Écrire un résultat attendu avant le build ne prouve pas que le système construit l’atteindra. Le test de référence fige l’entrée et l’attendu. Alors le test d’acceptation rejoue cette entrée après la construction, inscrit le constaté, attache la preuve et soumet l’écart au validateur.
| Moment | Ce qui est écrit | Ce que cela permet |
|---|---|---|
| Avant la construction | Entrée de référence et résultat attendu | Rendre la réussite, le refus ou l’arrêt observable |
| Après la construction | Résultat constaté et preuve | Comparer le comportement livré à l’attendu |
| Pendant la revue | Décision humaine et motif | Déployer, réviser ou arrêter dans le périmètre examiné |
Comment tester le routage fictif de demandes internes ?
Le scénario ci-dessous est entièrement fictif. Les hypothèses, les résultats constatés et la décision servent à montrer la méthode. Ils ne décrivent ni un client, ni un système exploité, ni une performance terrain.
Hypothèses de travail
- Des demandes internes arrivent dans une boîte partagée.
- Le système produit uniquement une proposition de routage. Il ne répond pas, ne modifie aucun dossier et n’attribue aucune tâche.
- Les seules sources permises sont le texte reçu, une liste approuvée de catégories et un annuaire approuvé des équipes.
- L’annuaire fait autorité pour le nom de la destination.
- Le coordinateur de la boîte accepte, corrige ou rejette chaque proposition.
Le brouillon attendu contient l’identifiant de la demande, la catégorie proposée, la destination proposée, l’entrée d’annuaire citée et une justification courte. Mais les demandes incomplètes, ambiguës, contradictoires, sensibles ou hors périmètre doivent s’arrêter ou passer au coordinateur selon le cas écrit.
Matrice d’acceptation remplie
Les cinq lignes reprennent le même jeu de référence avant et après la construction fictive. Or le constat ne remplace jamais l’attendu, et la preuve ne remplace jamais la décision.
| Entrée | Attendu | Constaté fictif | Preuve fictive | Décision |
|---|---|---|---|---|
| « La lumière du couloir B ne fonctionne plus », avec le site indiqué | Brouillon vers l’équipe des locaux, avec catégorie et entrée d’annuaire citées | Le brouillon contient les champs demandés et cite la destination prévue | Entrée T1, annuaire A1 et brouillon S1 conservés | Accepter ce cas |
| « La salle est inaccessible », sans site ni numéro de salle | Arrêt pour information manquante, sans destination inventée | Le manque est signalé et aucune destination n’est proposée | Entrée T2 et message d’arrêt S2 conservés | Accepter ce cas |
| « Mon badge ne marche plus sur le poste de prêt » | Passage au coordinateur, car la demande peut concerner un accès ou un équipement | Le brouillon propose directement l’équipe informatique | Entrée T3 et brouillon S3 conservés | Réviser la règle d’ambiguïté |
| La catégorie indique « locaux », mais l’annuaire associe la destination saisie à une autre équipe | Arrêt et présentation du conflit au coordinateur | Le workflow s’arrête, mais le message ne cite pas les deux références en conflit | Entrée T4, sources C1 et A1, message S4 conservés | Réviser la preuve du conflit |
| Demande marquée « sensible » dans le cas de référence | Aucun routage, transmission au coordinateur | Aucune destination n’est proposée et le coordinateur reçoit le cas | Entrée T5 et trace d’arrêt S5 conservées | Accepter ce cas |
Revue et décision
Décision fictive : réviser. Trois cas produisent le comportement attendu. Mais le cas ambigu contourne la validation humaine prévue, et le cas contradictoire ne montre pas les deux références nécessaires à la revue. La frontière reste utile ; les deux écarts sont observables. Donc le responsable corrige ces règles, rejoue les cinq cas et inscrit de nouveaux constats avant toute décision de déploiement.
Cet exemple reste volontairement étroit. Pour choisir le workflow avant d’écrire son contrat, consultez la méthode pour automatiser son entreprise avec l’IA. Pour suivre un autre scénario, voyez cet exemple de projet d’intelligence artificielle.
Quelle preuve faut-il produire à chaque porte ?
Un seul tableau ne doit pas mélanger le contrat, l’exécution et la revue. La fiche fixe la frontière du projet. Alors la matrice conserve les entrées, les attendus et les constats, et le compte rendu porte la décision humaine.
- Déployer si les cas requis ont une preuve inspectable, si les résultats constatés satisfont les attendus et si le validateur accepte uniquement la frontière testée.
- Réviser si la frontière reste exploitable mais qu’une source, une règle, un attendu, une preuve ou un passage à l’humain doit être corrigé.
- Arrêter si l’autorité des sources ne peut pas être établie, si le résultat ne peut pas être jugé avec les critères écrits, si un arrêt requis n’arrête rien ou si personne ne porte la décision.
Une nouvelle entrée, une nouvelle source, une nouvelle sortie ou une nouvelle action change la frontière. Donc elle demande ses propres cas de référence, constats et décisions.
Pour les projets qui traitent des données personnelles, la CNIL présente notamment la définition de la finalité, les responsabilités et la base légale, les droits des personnes, la minimisation et le contrôle des données, ainsi que la sécurité (CNIL). Mais cette fiche n’est ni un conseil juridique ni une preuve de conformité.
Quelles questions poser sur le cahier des charges d’un projet IA ?
Comment rédiger un cahier des charges pour un projet IA ?
Commencez par la frontière du workflow et les sources autorisées. Écrivez ensuite les résultats attendus sur des entrées de référence. Après la construction, consignez les résultats constatés et les preuves. La décision revient alors au validateur nommé.
Faut-il choisir le modèle ou la plateforme dans le cahier des charges ?
Un choix technique peut apparaître parmi les contraintes, mais il ne remplace pas la preuve d’acceptation. Une livraison s’examine sur ses entrées, ses sorties, ses arrêts, ses preuves et sa validation humaine.
Peut-on tout prévoir avant le build ?
Le contrat n’a pas à prédire toute l’implémentation. Il fixe la frontière observable et les conditions d’acceptation. Un écart découvert au test devient une décision documentée : accepter dans la frontière, réviser ou arrêter.
Ce modèle prouve-t-il la conformité au RGPD ?
Non. La CNIL présente plusieurs éléments à examiner pour un projet d’IA traitant des données personnelles, dont la finalité, les responsabilités et la base légale, les droits des personnes, la minimisation et le contrôle des données, ainsi que la sécurité (CNIL). Ce modèle n’est ni un conseil juridique ni une preuve de conformité.
Le cahier des charges cadre un projet précis. Pour poser des règles communes au-dessus de plusieurs usages, adaptez aussi cette charte IA d’entreprise en une page. Pour approfondir le rôle du validateur, consultez l’article sur l’intelligence artificielle en comptabilité.
Choisir la bonne porte
Vous avez la fiche, la matrice et une décision à porter. Si le cadrage demande un accompagnement, choisissez la porte qui correspond au travail.
Choisir la bonne porte