Cahier des charges IA : cadrer les données, les erreurs acceptables et le budget

Un cahier des charges IA doit préciser le problème à résoudre, les données utilisables et les conditions qui permettront d’accepter la solution. Décrire simplement un « assistant intelligent » ou un « outil prédictif » ne suffit pas : il faut expliquer ce que le système devra faire, dans quelles limites et sous quel contrôle humain.

Ce document sert autant à consulter des prestataires qu’à aligner les équipes métier, informatique, juridique et sécurité. Son rôle est de transformer une ambition en exigences vérifiables, sans imposer trop tôt une technologie.

Partir du travail réel, pas de la technologie souhaitée

La première partie du cahier des charges décrit la situation actuelle : qui réalise la tâche, avec quels outils, selon quelles règles et avec quelles difficultés. Une IA n’est pas nécessairement la meilleure réponse à tous les problèmes. Une recherche documentaire améliorée, une automatisation classique ou une réorganisation peuvent parfois suffire.

Définir un cas d’usage délimité

Préférez « préparer une réponse aux demandes de remboursement à partir des procédures internes » à « améliorer le service client grâce à l’IA ». La première formulation identifie une tâche, des connaissances à mobiliser et un résultat attendu. Précisez aussi les utilisateurs concernés, les volumes à traiter, les langues et les contraintes de délai.

Indiquez explicitement les exclusions. Un assistant peut rédiger un brouillon sans autoriser un remboursement, ou retrouver une clause sans fournir de conseil juridique. Le périmètre exclu protège autant le projet que le périmètre retenu.

Relier chaque objectif à une mesure

Un objectif comme « gagner du temps » doit être associé à une méthode de mesure. Vous pouvez suivre le temps consacré à une tâche, la proportion de propositions acceptées après vérification ou le nombre de dossiers nécessitant une reprise. Mesurez d’abord la situation existante pour disposer d’un point de comparaison crédible.

Le cahier des charges doit faire le pont entre le langage métier et les tests techniques. Pour chaque attente, construisez une chaîne simple : situation rencontrée, comportement attendu, preuve observable. Par exemple, « retrouver la bonne procédure » devient « présenter le document applicable et son passage justificatif ». Cette traduction évite qu’une démonstration convaincante soit confondue avec un service réellement utilisable.

Décrire les données et les droits avant de choisir le modèle

La faisabilité dépend largement des informations auxquelles le système pourra accéder. Un inventaire des données doit accompagner le besoin fonctionnel : documents, bases structurées, historiques de demandes, images ou enregistrements, selon le projet. Pour chaque ensemble, précisez son propriétaire, son format, sa qualité et ses conditions d’accès.

Vérifier la disponibilité et la qualité

Des fichiers présents sur un serveur ne sont pas nécessairement exploitables. Les documents peuvent être obsolètes, contradictoires, mal numérisés ou dépourvus de métadonnées. Demandez au prestataire d’expliciter les opérations nécessaires : extraction, nettoyage, dédoublonnage, annotation ou mise à jour.

• Identifier les sources de référence et les versions faisant autorité.
• Repérer les informations manquantes et les formats difficiles à traiter.
• Désigner les personnes responsables de la validation des contenus.
• Définir la fréquence d’actualisation et la gestion des suppressions.

Encadrer la confidentialité et les usages secondaires

Le document doit distinguer les données autorisées, sensibles et interdites. Il précise les règles d’hébergement, les habilitations, la conservation des échanges et les conditions d’accès des sous-traitants. Lorsqu’il y a des données personnelles, les obligations applicables, notamment au titre du RGPD, doivent être examinées avec les interlocuteurs compétents.

Ne présumez pas que les données transmises resteront sans autre usage. Demandez des engagements explicites sur leur éventuelle utilisation pour entraîner ou améliorer des modèles, ainsi que sur leur suppression. Les mêmes questions concernent les requêtes, les réponses, les journaux techniques et les sauvegardes.

Transformer les fonctions attendues en critères de recette

Un cahier des charges IA utile décrit les comportements à vérifier, pas seulement une liste de fonctionnalités. Selon le besoin, la solution pourra classer, extraire, recommander, prédire ou générer du contenu. Chaque fonction doit être associée à des entrées, des sorties et des règles de validation.

Définir les erreurs acceptables et les erreurs bloquantes

Toutes les erreurs n’ont pas la même gravité. Une suggestion maladroite n’a pas le même impact qu’une divulgation confidentielle ou qu’une instruction dangereuse. Classez les incidents selon leurs conséquences et précisez les situations qui imposent un refus, une alerte ou une intervention humaine.

Évitez de demander une « précision de 95 % » sans définir ce qui est mesuré. Pour une classification, il faut notamment distinguer les faux positifs des faux négatifs. Pour un texte généré, plusieurs critères peuvent être nécessaires : exactitude, complétude, fidélité aux documents et respect des consignes.

Préparer un jeu de tests représentatif

La recette doit inclure des cas courants, des exceptions, des entrées incomplètes et des tentatives de contournement. Réservez des exemples à l’évaluation finale, distincts de ceux utilisés pour régler la solution. Précisez qui évalue, selon quelle grille et avec quelles règles d’acceptation. Pour une IA générative, prévoyez plusieurs exécutions lorsque la variabilité des réponses peut influencer le résultat.

Cadrer l’intégration, les responsabilités et le coût d’exploitation

Une preuve de concept réussie ne garantit pas un déploiement viable. Le cahier des charges doit couvrir l’environnement réel : authentification, logiciels existants, interfaces, disponibilité attendue et assistance aux utilisateurs. Demandez au fournisseur de distinguer ses engagements, ses hypothèses et les dépendances qui échappent à son contrôle.

Prévoir le fonctionnement après la livraison

Désignez un responsable métier et un responsable technique. Décrivez le traitement des incidents, la surveillance de la qualité et la procédure de mise à jour. Une modification du modèle, des instructions ou du corpus documentaire peut changer les résultats : elle doit donc déclencher des vérifications adaptées.

Prévoyez également un mode dégradé. Si le service est indisponible ou si la réponse est incertaine, l’utilisateur doit savoir comment poursuivre son travail. La réversibilité doit couvrir les formats d’export, la récupération des configurations et les conditions de sortie du contrat.

Comparer le coût total, pas seulement le prototype

Le budget doit séparer le cadrage, la préparation des données, le développement, l’intégration et l’exploitation. Ajoutez les coûts de consommation, d’hébergement, de supervision, de maintenance et de contrôle humain. Demandez plusieurs hypothèses d’usage pour comprendre l’effet des volumes et des pics d’activité.

Pour obtenir des offres comparables, imposez une trame de réponse commune : solution proposée, écarts aux exigences, livrables, calendrier, responsabilités, prix et exclusions. Chaque promesse importante doit correspondre à un livrable ou à un test. C’est ce qui transforme le cahier des charges en outil de décision, puis en référence opérationnelle tout au long du projet.