Cahier des charges projet IA : le modèle opérateur

Un cahier des charges projet IA utile est un contrat d'acceptation, pas une liste d'outils. Il décrit le problème métier et la situation initiale observable, le workflow inclus dans le périmètre, ses exclusions explicites, les entrées permises et les sources qui font autorité. Il fixe la sortie attendue et les tests qui la rendent acceptable. Il nomme aussi la personne qui valide le résultat, les preuves et journaux à conserver, les cas qui doivent arrêter le workflow et le responsable du document. Sa dernière partie donne une date de revue et une décision nette : déployer, réviser ou arrêter. Un fournisseur peut alors proposer une réalisation sans redéfinir discrètement la réussite.

Pourquoi écrire un contrat d'acceptation plutôt qu'une liste d'outils ?

Une liste de modèles, de connecteurs et d'interfaces décrit un achat souhaité, pas une preuve attendue. Le contrat d'acceptation remet le résultat observable au centre. Le responsable métier, l'équipe technique et le fournisseur partagent ainsi la même frontière pour examiner une livraison.

Le document n'a pas à prédire toute la réalisation technique. Il doit rendre les désaccords visibles. Une entrée interdite est nommée. Deux sources approuvées qui se contredisent provoquent un arrêt. Une sortie soumise à validation reste un brouillon, même si l'interface semble terminée.

Le NIST AI Risk Management Framework est volontaire et vise à aider les organisations à 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 Govern, Map, Measure et Manage. Le Playbook associé propose des actions volontaires : ce n'est ni une checklist ni une séquence obligatoire. Le modèle de cet article est une recommandation éditoriale distincte et ne revendique ni certification, ni conformité, ni suffisance juridique.

Quelles sont les sept parties à copier ?

Copiez ces sept titres dans votre document de travail et exigez une réponse concrète sous chacun. Une réponse vide, vague ou contestée indique que le projet n'est pas prêt à être accepté sur ce point.

1. Problème et situation initiale observable. Décrivez le problème métier sans nommer de solution. Notez ce qui est observable aujourd'hui et comment la même observation sera produite lors de la revue.
2. Workflow inclus et exclusions explicites. Nommez l'événement qui lance le travail, le point où il s'achève, les personnes ou systèmes concernés et tout ce que le projet ne doit pas faire.
3. Entrées autorisées et autorité des sources. Listez les formats et dépôts permis. Précisez quelle source prévaut. Sans autorité ou face à une contradiction, imposez l'arrêt.
4. 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 conditions de validation ou de rejet.
5. Jeu de tests. Incluez des cas normaux, incomplets, ambigus, contradictoires et sensibles. Chaque cas reçoit un résultat attendu, y compris un refus ou une transmission à l'humain.
6. Validation humaine, échec, arrêt et preuves. Nommez le point de décision, le comportement en échec et la voie d'arrêt. Listez les versions d'entrée et de sortie, les sources, la décision, l'exception et la correction conservées.
7. Responsable et décision de revue. Nommez la personne qui maintient règles, sources et tests, donnez une date de revue et consignez une décision : déployer dans le périmètre testé, réviser ou arrêter.

Le guide pratique de France Num recommande de formaliser objectifs, rôles et règles, de tester avant le déploiement, de garder une supervision humaine pour les tâches sensibles, d'assurer la traçabilité et de maintenir les instructions, la configuration et les documents. Il s'agit de conseils pratiques, pas d'une règle de droit contraignante.

Quel tableau peut-on copier directement ?

Ce tableau est l'artefact de travail compact : une ligne par décision qui devra laisser une preuve. Ajoutez les détails propres au projet, mais ne remplacez pas une preuve par des adjectifs comme « intelligent », « fluide » ou « précis ».

Comment construire le jeu de tests ?

Testez la frontière et le refus, pas seulement le beau cas nominal. Chaque cas contient une entrée fournie, une sortie ou un arrêt attendu, le résultat constaté, le nom du validateur et sa décision. Conservez des cas assez stables pour comparer les révisions du projet.

• Normal : une entrée complète et autorisée, issue d'une source de référence, produit la sortie prévue pour validation humaine.
• Incomplet : un champ ou une source manque ; le workflow signale le manque sans l'inventer.
• Ambigu : plusieurs lectures sont possibles ; le workflow demande une décision humaine.
• Contradictoire : des sources permises divergent ; le workflow montre le conflit et s'arrête.
• Sensible : le cas appartient à la catégorie sensible nommée ou sort du périmètre ; aucune action non autorisée n'a lieu.

Pour un système d'IA traitant des données personnelles, la CNIL présente le travail autour de la définition de la finalité, des responsabilités et de la base légale, de la protection des droits des personnes, de la minimisation et du contrôle des données, et des mesures de sécurité. Un tel projet exige une revue juridique et vie privée adaptée ; ce modèle n'est pas un conseil juridique et ne prouve pas la conformité au RGPD.

À quoi ressemble un exemple fictif rempli ?

L'exemple suivant de routage de demandes internes est hypothétique et ne promet aucun gain de productivité. Il sert uniquement à montrer des champs remplis.

1. Problème et situation initiale. Des demandes internes arrivent dans une boîte partagée. La situation initiale est un échantillon daté qui contient le texte de la demande, la catégorie choisie par une personne et l'équipe destinataire.
2. Périmètre et exclusions. Le workflow commence à l'arrivée d'une demande interne et finit par une proposition de routage. Il ne répond pas, ne modifie aucun dossier, n'attribue aucune tâche et ne traite pas les demandes externes.
3. Entrées et autorité. Les entrées permises sont le texte, la liste approuvée des catégories et l'annuaire approuvé des équipes. L'annuaire fait autorité pour le nom des destinations. Si une catégorie ou une destination manque, le workflow s'arrête.
4. Sortie et acceptation. Le brouillon contient l'identifiant, la catégorie proposée, la destination proposée, l'entrée d'annuaire citée et une justification courte. Il est accepté si tous les champs sont présents et si les sources fournies soutiennent la proposition.
5. Tests. Le jeu comprend une demande claire liée aux locaux, une demande sans lieu, une formulation pouvant désigner un accès ou un équipement, une catégorie et un annuaire qui indiquent des équipes différentes, puis une demande signalée sensible. Les résultats attendus sont : brouillon, arrêt pour manque, décision humaine, arrêt pour conflit et arrêt sensible.
6. Validation, arrêt et preuves. Le coordinateur de la boîte accepte, corrige ou rejette chaque proposition. Les demandes incomplètes, ambiguës, contradictoires, sensibles ou hors périmètre ne sont pas routées. La trace conserve les versions des entrées et sources, le brouillon, la décision, l'exception et la correction.
7. Responsable et revue. Le responsable des opérations maintient catégories, annuaire et tests. Le compte rendu de revue porte une date et conclut : déployer dans la frontière testée, réviser ou arrêter.

Cet exemple est plus étroit que l'article consacré à un exemple de projet d'intelligence artificielle. Pour l'étape précédente de sélection du workflow, utilisez la méthode pour automatiser son entreprise avec l'IA.

Quels signaux révèlent une simple liste de souhaits fournisseur ?

Le document est faible quand le vocabulaire du produit est précis mais que l'acceptation reste vague. Ces signaux imposent une réécriture avant de comparer des offres :

• le document commence par un modèle, une plateforme ou une intégration au lieu du problème et de la situation initiale ;
• le périmètre vise tout un service sans exclusion explicite ;
• les entrées sont appelées « données de l'entreprise » sans source permise ni autorité ;
• la sortie doit être « de qualité » sans format ni critères de réussite et d'échec ;
• le jeu de tests ne contient que des exemples favorables ;
• la revue humaine est citée sans nommer le validateur ni le point de décision ;
• des journaux sont demandés sans définir les preuves à conserver ;
• l'échec déclenche seulement une nouvelle tentative, sans arrêt ni passage à l'humain ;
• personne ne possède les sources, les tests, la maintenance et la date de revue.

Comment décider de déployer, réviser ou arrêter ?

La porte de décision est courte parce que les preuves ont déjà été définies.

• Déployer : chaque test requis possède un résultat inspectable, les critères sont satisfaits, les cas d'arrêt s'arrêtent, la validation humaine fonctionne et le responsable n'accepte que le périmètre testé.
• Réviser : le problème reste valable, mais une règle, une entrée, une source, un critère de sortie, un test ou la voie de validation est incomplet. Modifiez le contrat puis testez à nouveau.
• Arrêter : les entrées requises ou leur autorité ne peuvent être établies, la sortie ne peut être jugée avec des critères écrits, l'arrêt échoue ou personne n'accepte la responsabilité.

La décision de déployer ne valide pas un périmètre élargi. Une nouvelle entrée, source, sortie ou action modifie le contrat et réclame ses tests et sa revue.

Le cahier des charges cadre un projet précis. Pour poser les règles communes au-dessus de plusieurs usages, adaptez aussi cette charte IA d'entreprise en une page.

FAQ sur le cahier des charges d'un projet IA

Comment rédiger un cahier des charges pour un projet IA ? Rédigez-le comme un contrat d'acceptation. Définissez la situation observable, le périmètre et ses exclusions, les entrées autorisées, la sortie, les tests, la validation humaine, les arrêts, les preuves, le responsable et la décision de revue.

Quelles sont ses principales composantes ? Utilisez sept parties : problème et situation initiale ; périmètre et exclusions ; entrées et autorité des sources ; sortie et critères ; tests ; validation, arrêts et preuves ; responsabilité, maintenance et revue.

Quelles sont les étapes d'un projet IA ? Dans ce modèle opérateur, écrivez le contrat, constituez les tests, testez dans le périmètre, relisez les preuves, puis décidez de déployer, réviser ou arrêter. C'est une recommandation éditoriale, pas un cadre universel.

Ce modèle prouve-t-il la conformité au RGPD ? Non. Selon la CNIL, un projet traitant des données personnelles exige une revue juridique et vie privée adaptée. Ce modèle est un document opératoire, pas un conseil juridique ni une preuve de conformité.