Cahier des charges IA : des critères de réussite avant le choix du modèle

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 chatbot intelligent » ou « une automatisation par IA » ne suffit pas : un prestataire doit pouvoir estimer le travail, et votre équipe doit pouvoir vérifier le résultat. Le document sert donc à transformer une ambition en exigences testables, sans imposer trop tôt une technologie.

Partir du travail à accomplir, pas du modèle à acheter

Le premier arbitrage consiste à déterminer ce que l’intelligence artificielle doit réellement améliorer. Un besoin mal défini peut conduire à développer une solution complexe alors qu’un moteur de recherche, une règle métier ou une meilleure organisation suffirait. Le cahier des charges doit laisser la possibilité de comparer ces options.

Décrire une situation concrète et son résultat attendu

Présentez les utilisateurs concernés, leur tâche actuelle et la difficulté rencontrée. Pour un assistant documentaire interne, précisez par exemple qui cherche l’information, dans quels documents et pour quelle décision. « Aider les équipes support à retrouver une procédure validée » est plus exploitable que « valoriser notre patrimoine documentaire ».

Décrivez ensuite le résultat attendu sans le confondre avec une fonctionnalité. Une interface conversationnelle est un moyen ; retrouver une réponse vérifiable sans parcourir plusieurs dossiers est un résultat. Le besoin métier doit rester compréhensible indépendamment de la technologie retenue.

Fixer les limites dès le départ

Indiquez ce que la solution peut faire, ce qu’elle ne doit pas faire et les situations qui nécessitent une intervention humaine. Un outil peut préparer une réponse sans être autorisé à l’envoyer. Il peut résumer un contrat sans formuler de recommandation juridique. Ces frontières déterminent l’interface, les permissions et les responsabilités.

• Les utilisateurs et les situations couverts par la première version.
• Les langues, formats et canaux pris en charge.
• Les actions autorisées, interdites ou soumises à validation.
• Les cas exclus et leur mode de traitement alternatif.

Définir la réussite avec des tests observables

Un système d’IA peut produire une réponse convaincante mais incorrecte. Le cahier des charges doit donc décrire ce qui sera évalué, sur quels exemples et selon quelle méthode. Les critères de réception ne doivent pas être négociés seulement après la démonstration du prestataire.

Constituer un jeu d’essai représentatif

Rassemblez des situations réelles, anonymisées si nécessaire : demandes simples, formulations ambiguës, documents contradictoires, informations absentes et tentatives de contournement. Pour chaque cas, indiquez le comportement attendu. Il peut s’agir d’une réponse correcte, mais aussi d’une demande de précision, d’un refus ou d’un transfert à un opérateur.

Réservez une partie des cas à l’évaluation finale afin de ne pas mesurer uniquement l’adaptation aux exemples de développement. Faites valider les réponses attendues par les personnes compétentes sur le métier concerné.

Associer chaque seuil à une règle de décision

Évitez les engagements vagues comme « une grande précision ». Précisez le calcul de l’indicateur, le seuil visé, les erreurs considérées comme bloquantes et la procédure de correction. Une bonne moyenne ne doit pas masquer une fuite de données ou une action non autorisée. Distinguez les défauts tolérables, ceux qui nécessitent une reprise et ceux qui interdisent la mise en production.

Encadrer les données, les accès et les usages sensibles

La qualité d’une solution dépend notamment des informations qu’elle peut exploiter. Le cahier des charges IA doit inventorier les documents, bases et applications concernés, mais aussi leur état : doublons, versions obsolètes, formats difficilement lisibles ou droits d’accès incomplets. Cette préparation représente un chantier à part entière, à répartir explicitement entre client et prestataire.

Documenter le parcours des données

Précisez où les données sont stockées, comment elles sont transmises et quels acteurs peuvent y accéder. Demandez au prestataire d’expliciter l’utilisation des requêtes, des réponses et des journaux techniques : conservation, réutilisation éventuelle pour l’entraînement, suppression et sous-traitants impliqués. Ne supposez pas qu’un hébergement donné règle à lui seul toutes les questions de confidentialité.

Lorsque des données personnelles sont concernées, faites examiner les finalités, les durées de conservation et les mesures de protection par les interlocuteurs compétents, notamment le délégué à la protection des données lorsqu’il existe. Les obligations applicables dépendent de l’usage et du rôle des acteurs ; elles doivent être vérifiées avant le déploiement.

Préserver les droits jusqu’à la réponse finale

Un assistant connecté à plusieurs espaces documentaires ne doit pas rendre accessible, par sa réponse, un contenu que l’utilisateur ne pourrait pas consulter directement. Exigez des contrôles sur la recherche documentaire, la génération et les références affichées. Prévoyez également des tests face aux instructions malveillantes insérées dans les documents ou les messages.

Prévoir l’intégration et le fonctionnement quotidien

Une démonstration réussie ne garantit pas un service exploitable. Décrivez l’environnement cible : authentification, logiciels existants, interfaces de programmation, contraintes réseau et modalités de déploiement. Demandez une distinction claire entre les composants standards, les développements spécifiques et les dépendances à des services tiers.

Pensez la chaîne technique comme une corde composée de plusieurs brins : documents, moteur de recherche, modèle, permissions et interface. Renforcer un seul brin ne sécurise pas l’ensemble. Traduisez cette image en exigence pratique : chaque réponse problématique doit pouvoir être examinée pour distinguer une information absente, une recherche défaillante, un document périmé ou une erreur de génération. Cette traçabilité évite de changer de modèle pour corriger un problème documentaire.

Organiser les incidents et les changements

Identifiez qui surveille le service, reçoit les signalements et décide d’une suspension. Prévoyez un mode dégradé : retour à la recherche classique, transfert humain ou désactivation d’une fonction sensible. Les utilisateurs doivent savoir quand ils interagissent avec une IA et comment contester un résultat.

Définissez aussi les vérifications à refaire lorsqu’un modèle, une instruction ou un corpus change. La recette n’est pas seulement une étape avant lancement : les modifications importantes doivent déclencher des tests de non-régression adaptés.

Rendre les offres comparables et la sortie possible

Pour consulter des prestataires, fournissez une trame de réponse commune. Demandez que chaque exigence soit qualifiée : couverte en standard, réalisable avec adaptation, non couverte ou dépendante d’un tiers. Les hypothèses et les exclusions doivent apparaître aussi clairement que les engagements.

Décomposer le budget et les livrables

Séparez le cadrage, la préparation des données, l’intégration, les tests, la formation et l’exploitation. Pour les coûts variables, demandez les unités de facturation et plusieurs scénarios d’usage. Incluez la maintenance documentaire, la supervision et le temps de validation humaine : le prix d’accès au modèle ne représente pas tout le coût du service.

Listez les livrables attendus : documentation technique, résultats des tests, procédures d’administration, supports de formation et éléments nécessaires à la reprise. Précisez les droits d’utilisation et les conditions d’accès aux configurations, au code spécifique et aux données produites.

Découper les engagements avant de généraliser

Un pilote doit lever des incertitudes identifiées, pas simplement produire une démonstration séduisante. Associez-lui un périmètre, des critères de passage et une décision possible d’arrêt. Avant la généralisation, vérifiez la qualité, la sécurité, l’adoption par les utilisateurs et le coût réel. Enfin, prévoyez la réversibilité : formats d’export, restitution des données, suppression des copies et accompagnement au changement de fournisseur.