Cahier des charges IA : les étapes pour cadrer un projet utile

Un cahier des charges IA utile ne commence pas par le choix d’un modèle ou d’un fournisseur. Il décrit un problème métier observable, les données réellement disponibles, le résultat attendu, les erreurs acceptables et la personne qui garde la décision finale. Son rôle est simple : permettre à une équipe de décider si le projet mérite d’être lancé, puis de vérifier la livraison sans se fier à une démonstration séduisante.

Ce document peut rester court au départ. Une dizaine de pages précises vaut mieux qu’un dossier volumineux rempli d’hypothèses. Il doit surtout rendre visibles les inconnues. Si la qualité des données, le coût d’une erreur ou le responsable de la validation ne sont pas connus, il faut l’écrire et prévoir une phase d’exploration.

1. Formuler le problème avant de parler d’intelligence artificielle

« Automatiser le service client avec l’IA » est une intention, pas un besoin exploitable. Une formulation plus solide serait : « aider les conseillers à retrouver la bonne procédure dans la documentation interne, sans envoyer automatiquement de réponse au client ». Elle nomme l’utilisateur, l’action assistée et une limite importante.

Le cahier des charges doit préciser la situation actuelle : comment la tâche est-elle réalisée, par qui, à quelle fréquence et avec quelles difficultés ? Cette référence servira à comparer la solution future avec l’existant. Sans point de départ, un gain annoncé reste impossible à vérifier.

Ajoutez aussi une question volontairement inconfortable : une règle métier, une amélioration de l’interface ou un moteur de recherche classique suffiraient-ils ? L’IA n’est pertinente que si elle apporte quelque chose à un problème caractérisé. Le projet doit pouvoir être arrêté à cette étape si une solution plus simple répond mieux au besoin.

La fiche de cadrage en six lignes

Utilisateur : qui se sert du système et dans quel contexte ?
Tâche : quelle action précise doit être facilitée ou automatisée ?
Résultat : quel livrable ou quelle décision est attendu ?
Référence actuelle : comment mesure-t-on aujourd’hui le délai, la qualité ou le coût ?
Limites : que le système ne doit-il jamais faire seul ?
Alternative : pourquoi une solution sans IA ne suffit-elle pas ?

2. Délimiter un premier cas d’usage testable

Un premier périmètre doit être assez petit pour être évalué sur des cas réels. « Traiter tous les documents de l’entreprise » ouvre trop de variantes. « Extraire cinq champs définis de factures françaises au format PDF, puis soumettre le résultat à un comptable » permet déjà de préparer des tests.

Séparez les exigences indispensables des améliorations futures. Décrivez les entrées acceptées, la sortie attendue, les utilisateurs concernés, les outils à connecter et les cas exclus. Une liste d’exclusion protège le calendrier : langues non prises en charge, documents manuscrits, décisions à fort impact ou données auxquelles l’équipe n’a pas accès.

Cette étape aide aussi à choisir le mode de réalisation. Le guide ADE University sur le choix entre internalisation, sous-traitance et organisation hybride propose une grille fondée sur les données, la valeur stratégique et les compétences disponibles. Ce choix vient après le cadrage, car un prestataire ne devrait pas définir seul le problème de son client.

3. Inventorier les données sans les idéaliser

Un cahier des charges IA doit décrire les données accessibles, pas celles que l’on espère récupérer un jour. Pour chaque source, indiquez le propriétaire, le format, la période couverte, la fréquence de mise à jour, les droits d’accès et les défauts déjà connus. Quelques échantillons anonymisés sont souvent plus instructifs qu’une volumétrie théorique.

Documentez les valeurs manquantes, doublons, catégories déséquilibrées et changements de méthode de saisie. Précisez qui nettoie ou annote les données et qui valide ce travail. Si des données personnelles sont utilisées, le sujet ne peut pas être renvoyé à la fin du projet. La CNIL rappelle notamment qu’une finalité doit être définie en amont et que les phases d’apprentissage et de production peuvent répondre à des objectifs distincts.

Le document doit donc poser noir sur blanc les finalités, les catégories de données, les durées de conservation envisagées, les personnes autorisées et la base légale à examiner avec le DPO ou le conseil compétent. La grille d’auto-évaluation de la CNIL fournit un parcours utile, de la qualification des données jusqu’à la production et à l’exercice des droits.

4. Transformer les attentes en critères d’acceptation

« Le système doit être précis » ne permet pas de prononcer une recette. Chaque attente doit devenir un test assorti d’une règle de décision. Pour un outil d’extraction, on peut mesurer séparément la qualité de chaque champ. Pour un assistant documentaire, on peut vérifier si la réponse s’appuie sur la bonne source, si elle cite cette source et si elle sait s’abstenir lorsque l’information manque.

Question à trancher	Élément à écrire dans le cahier des charges
Que mesure-t-on ?	Un indicateur métier et un indicateur technique clairement définis
Sur quels cas ?	Un jeu de test représentatif, séparé des données de conception
Quelle erreur compte le plus ?	Le coût d’un faux positif, d’un oubli ou d’une réponse inventée
Quel seuil permet d’avancer ?	Un minimum d’acceptation fixé avant la démonstration finale
Qui décide ?	Un responsable nommé, avec une procédure en cas de désaccord

Le coût des erreurs mérite une section entière. Confondre deux thèmes dans une bibliothèque interne n’a pas la même conséquence que refuser à tort un dossier ou révéler une information confidentielle. Selon le cas, le bon objectif n’est pas de maximiser un score global, mais de réduire une erreur particulière et d’imposer une validation humaine.

5. Prévoir les cas limites et la place du contrôle humain

Un système d’IA produit rarement une réponse uniformément fiable. Le cahier des charges doit expliquer ce qui se passe lorsque le niveau de confiance est faible, qu’un document est illisible, qu’une demande sort du périmètre ou que deux sources se contredisent. Une réponse utile peut être un refus explicite, une demande de précision ou un transfert vers une personne.

Construisez avant le développement une petite bibliothèque de cas difficiles : données incomplètes, formulation ambiguë, contenu malveillant, changement de langue, information absente et tentative d’obtenir une donnée interdite. Pour chaque cas, décrivez le comportement attendu. Cette bibliothèque deviendra un actif de recette puis de surveillance.

La validation humaine doit être concrète. Qui reçoit l’alerte ? De quelles informations cette personne dispose-t-elle ? Peut-elle corriger, annuler et signaler l’erreur ? Dans quel délai ? Écrire seulement « human in the loop » ne règle rien si aucun rôle, écran ni délai n’est prévu.

6. Cadrer la sécurité, les accès et les fournisseurs

Listez les environnements de développement, de test et de production, les profils d’accès, les journaux nécessaires et les règles de conservation. Pour une IA générative, précisez si les requêtes ou documents peuvent être réutilisés par un fournisseur, où les données sont traitées et comment les secrets sont retirés des entrées.

L’ANSSI publie des recommandations de sécurité pour les systèmes d’IA générative. Elles peuvent alimenter une revue menée avec les responsables de la sécurité, sans transformer le cahier des charges en audit technique improvisé.

Pour les usages d’outils accessibles au grand public, le dossier ADE University consacré à la confidentialité et aux limites de ChatGPT sans compte rappelle un réflexe simple : l’absence de création de compte ne dispense pas de vérifier les conditions du service ni de protéger les informations saisies.

7. Organiser le projet en étapes avec des décisions de poursuite

Un calendrier crédible ne relie pas directement le brief à la mise en production. Il prévoit une exploration des données, un prototype limité, une évaluation, un pilote avec de vrais utilisateurs, puis une décision de déploiement. À chaque jalon correspondent un livrable, un responsable et une condition de poursuite.

Cadrage : problème, périmètre, parties prenantes et hypothèses validés.
Faisabilité : échantillon de données examiné, risques majeurs et solution sans IA comparés.
Prototype : comportement central testé hors production sur un périmètre fermé.
Pilote : utilisateurs identifiés, support organisé et indicateurs observés en situation réelle.
Production : sécurité, documentation, exploitation et procédure de retour arrière prêtes.

Prévoyez dès le départ les motifs d’arrêt : données insuffisantes, seuil minimal non atteint, coût d’exploitation disproportionné ou risque impossible à réduire. Arrêter un projet après une étude de faisabilité n’est pas un échec si cette étude évite un déploiement inutile.

8. Nommer les responsables après la livraison

Le cahier des charges doit couvrir le fonctionnement quotidien, pas seulement la livraison. Nommez le propriétaire métier, le responsable technique, la personne qui suit les incidents et celle qui autorise une nouvelle version. Définissez la fréquence des contrôles, les signaux de dégradation et le chemin de retour vers la version précédente.

Ajoutez les livrables attendus : documentation des données, protocole d’évaluation, résultats des tests, limites connues, guide utilisateur, journal des versions et procédure d’arrêt. Si un fournisseur intervient, précisez les formats de restitution, les droits d’usage, la réversibilité et le transfert de connaissances.

Les compétences nécessaires ne concernent pas uniquement les développeurs. Les utilisateurs doivent savoir contrôler une sortie, les managers arbitrer un cas d’usage et les fonctions support reconnaître les risques. Le guide sur les compétences IA à développer en entreprise permet de distinguer ces besoins selon les rôles.

La vérification finale avant d’envoyer le document

Relisez le cahier des charges avec une personne métier et une personne technique. Chacune doit pouvoir expliquer le problème, les exclusions, le jeu de test et la règle de décision. Vérifiez ensuite que chaque exigence peut être observée ou testée. Les mots « intelligent », « intuitif », « performant » ou « sécurisé » doivent être remplacés par un comportement, une preuve attendue ou une méthode de contrôle.

Le document est prêt lorsqu’il permet de répondre à trois questions sans improviser : pourquoi ce projet existe-t-il, comment saura-t-on qu’il fonctionne et qui prend la responsabilité lorsqu’il se trompe ? C’est ce niveau de précision qui transforme une idée d’IA en projet pilotable.

FAQ sur le cahier des charges IA

Qui doit rédiger le cahier des charges d’un projet IA ?

Le pilotage peut revenir à un chef de projet, mais la rédaction doit réunir le métier, la technique, les personnes responsables des données et, selon les risques, le DPO ou la sécurité. Le métier définit le problème et les erreurs acceptables. L’équipe technique vérifie la faisabilité et traduit les attentes en tests.

Quelle différence entre cahier des charges fonctionnel et spécifications techniques ?

Le cahier des charges fonctionnel décrit ce que l’utilisateur doit pouvoir accomplir, dans quelles conditions et avec quelles limites. Les spécifications techniques détaillent l’architecture et les moyens retenus. Pour éviter de figer trop tôt la solution, commencez par le comportement attendu, puis faites valider les choix techniques.

Faut-il choisir le modèle d’IA dans le cahier des charges ?

Seulement si une contrainte vérifiée l’impose. Dans la plupart des cas, mieux vaut définir les données autorisées, les performances attendues, le budget, la latence, l’hébergement et la réversibilité. Plusieurs solutions peuvent alors être comparées sur le même protocole, sans confondre une marque avec le besoin.

Camille Renaud, signature éditoriale d’ADE University.