Rédiger le cahier des charges d'un projet d'agent IA

En résumé. Un cahier des charges classique décrit des fonctions et se recette en cochant des cases : le bouton existe ou n’existe pas. Un agent IA ne se recette pas comme ça, parce qu’il produit des réponses justes ou fausses selon les cas, jamais présentes ou absentes. Deux sections manquent donc dans la quasi-totalité des documents que je reçois : un jeu de cas de test réels avec les réponses attendues, et un seuil de qualité chiffré à atteindre avant mise en production. Sans elles, personne ne peut dire si le projet est livré. La trame complète est plus bas, à copier et à remplir.

Pourquoi le cahier des charges classique échoue ici

Un développement logiciel traditionnel est déterministe. Vous demandez un formulaire à six champs qui enregistre une commande, et à la recette, soit il le fait, soit il ne le fait pas.

Un agent IA est probabiliste. Il extrait correctement les lignes d’une facture dans 94 % des cas et se trompe dans les 6 % restants, sur des documents qui n’ont rien de particulier. La question de la recette n’est plus « est-ce que ça marche » mais « à partir de quel taux acceptez-vous de le mettre en production, et qui traite le reste ».

Trois conséquences pratiques.

Un périmètre s’écrit en cas d’usage précis, pas en fonctionnalités. « Traiter les emails entrants » ne veut rien dire ; « classer les emails du service client en cinq catégories et rédiger un projet de réponse pour les demandes de suivi de commande » se teste.

La qualité s’écrit en chiffres. Un seuil, mesuré sur un échantillon défini, avant mise en service.

Les exceptions font partie du périmètre, pas des imprévus. Ce que le système ne sait pas traiter doit aller quelque part, et quelqu’un doit s’en occuper.

La trame, section par section

Copiez cette structure, remplissez-la avec vos données. Comptez une quinzaine de pages pour un premier périmètre, pas cinquante.

1. Contexte et objectif

Le processus concerné aujourd’hui, décrit en trois paragraphes. Qui fait quoi, avec quels outils, combien de temps ça prend. Le problème que vous cherchez à régler, formulé en une phrase. Le gain attendu, chiffré : heures récupérées par semaine, délai de traitement visé, taux d’erreur actuel.

Si vous ne pouvez pas chiffrer le gain attendu, arrêtez-vous ici. Ce n’est pas une clause de style : sans point de départ mesuré, aucun prestataire ne pourra démontrer un résultat, et vous paierez sans savoir ce que vous avez obtenu.

2. Périmètre fonctionnel

La liste des cas d’usage traités, un par un, dans l’ordre de priorité. Pour chacun : le déclencheur (un email arrive, un fichier est déposé, un utilisateur pose une question), le traitement attendu, la sortie produite, la destination de cette sortie.

Et surtout, la liste de ce qui n’est pas dans le périmètre. Cette section évite les trois quarts des désaccords de fin de projet.

3. Données et documents d’entrée

Les types de documents traités, leur volume mensuel, leur provenance. La qualité réelle des entrées : documents natifs ou scannés, structure stable ou variable, langue, présence de manuscrit.

Joignez vingt exemples réels et anonymisés, dont vos cinq documents les plus pénibles. Ce point pèse plus lourd que tout le reste du document réuni. Un prestataire qui chiffre sans avoir vu vos documents chiffre au hasard.

4. Règles métier

La partie la plus longue à écrire et la plus utile. Que fait le système quand la référence n’existe pas, quand le montant dépasse un seuil, quand deux informations se contredisent, quand un champ est illisible, quand le client commande sous une désignation à lui.

Ces règles ne sont écrites nulle part dans la plupart des entreprises. Elles vivent dans la tête de deux ou trois personnes. Les faire sortir représente la moitié du travail de cadrage, et c’est un travail que le prestataire ne peut pas faire seul.

5. Intégrations

Les systèmes à connecter, nommés avec leur version : ERP, CRM, messagerie, GED, base de données. Pour chacun, l’existence ou non d’une API, la documentation disponible, le contact technique côté éditeur, et qui détient les droits d’accès.

Précisez le sens de l’échange, en lecture, en écriture ou les deux, et si un environnement de test existe. Un projet sans environnement de test se recette en production, ce qui n’est pas une bonne idée.

6. Jeu de test et seuil de qualité

La section que personne n’écrit et qui décide de tout.

Constituez entre vingt et cinquante cas réels, avec pour chacun la réponse attendue. Prenez des cas ordinaires, des cas limites et des cas que vos équipes traitent mal. Ce jeu sert à trois choses : chiffrer honnêtement, mesurer pendant le développement, et prononcer la recette.

Fixez ensuite le seuil : la proportion de cas devant être traités correctement avant mise en production, mesurée sur ce jeu. Huit sur dix est un plancher raisonnable pour une tâche assistée par un humain ; un traitement sans relecture demande davantage. Écrivez aussi ce qui compte comme erreur, parce que « à peu près juste » n’est pas une catégorie mesurable.

7. Traitement des exceptions

Où partent les cas que le système ne sait pas traiter, qui les voit, dans quel délai, avec quelle information sur le motif du blocage. Un système sans file d’exceptions traitée par un humain finit par forcer des décisions douteuses en production.

8. Contraintes techniques et réglementaires

L’hébergement souhaité et sa localisation. La nature des données traitées et leur sensibilité : données personnelles, données de santé, secrets d’affaires. Les durées de conservation. Les exigences de traçabilité et de journalisation.

Si des données personnelles sont traitées, indiquez qui est votre référent et si une analyse d’impact est nécessaire. Cette question se pose au cadrage, pas trois jours avant la mise en production.

9. Livrables et engagements de sortie

Le code et sa cession, la documentation technique attendue, les accès à l’infrastructure ouverts à votre nom, la procédure de reprise par un tiers. Chiffrez le délai de reprise attendu.

10. Planning, budget et gouvernance

Le jalonnement, la date de mise en service visée, l’enveloppe. Le nom de la personne qui décide côté client et sa disponibilité réelle : comptez deux heures par semaine pendant le développement. En dessous, le projet dérive, et ce n’est pas une question de budget.

Les erreurs qui coûtent le plus cher

Écrire une solution plutôt qu’un problème. « Nous voulons un chatbot connecté à notre base documentaire » ferme la discussion avant qu’elle commence. « Nos commerciaux passent deux heures par jour à chercher des informations produit dans quatre systèmes » l’ouvre, et la réponse technique n’est pas forcément un chatbot.

Ne pas joindre de documents réels. Un chiffrage sur description est une fiction. Vos documents sont plus sales que vous ne le pensez, et c’est vrai chez tout le monde.

Confondre pilote et déploiement. Un cahier des charges qui décrit vingt cas d’usage sur cinq services produit un devis à six chiffres et un projet qui n’aboutit pas. Un premier périmètre se traite en quinze à trente jours de développement, sur un seul processus, avec des utilisateurs identifiés.

Oublier l’exploitation. L’agent tourne après la livraison. Qui surveille, qui corrige, qui adapte quand votre logiciel métier change de version. Un cahier des charges qui s’arrête à la mise en service prépare un projet qui s’arrête en année deux.

Faut-il passer par une AMOA ?

Le marché propose des cabinets d’assistance à maîtrise d’ouvrage, et des ESN vendent la phase de cadrage comme une prestation séparée. Trois situations, trois réponses.

Projet à moins de 50 000 €, un seul processus concerné : rédigez le document en interne avec la trame ci-dessus, puis faites-le relire par un développeur qui connaît le sujet. Une AMOA à ce niveau coûte une part significative du projet pour un gain limité.

Plusieurs directions concernées, arbitrages politiques internes : l’AMOA se justifie, moins pour la partie technique que pour le travail de mise d’accord entre services, qui est un vrai métier.

Vous ne savez pas quel processus automatiser en premier : ce n’est pas un besoin d’AMOA, c’est un besoin d’audit. Cadrez le périmètre avant d’écrire un cahier des charges sur un sujet qui n’est peut-être pas le bon.

Un point d’attention sur le cadrage vendu par le prestataire qui réalisera ensuite le projet. Ce n’est pas disqualifiant, c’est même souvent efficace, à une condition : que le livrable soit exploitable par un autre prestataire. Un cadrage qui aboutit systématiquement à un devis du même fournisseur, sans document réutilisable, était un acte commercial.

Combien de temps ça prend

Pour un premier périmètre sur un processus, comptez deux à quatre jours de travail côté client, répartis sur deux à trois semaines. La constitution du jeu de test et la formalisation des règles métier représentent l’essentiel de ce temps.

C’est du temps de vos meilleures personnes sur le processus concerné, pas du temps de stagiaire. Le document produit vaut ce que vaut la connaissance de celui qui l’écrit.

Et ce temps est rentable même si le projet ne se fait pas. Un processus dont les règles sont écrites et dont les exceptions sont mesurées est déjà mieux tenu qu’un processus qui vit dans la tête de trois personnes. Quand ce travail n’a jamais été fait, l’audit d’automatisation le produit en une semaine, et le document reste le vôtre même si la suite se fait ailleurs.

---

Trame issue des projets d’automatisation livrés en PME. Elle couvre un premier périmètre sur un processus ; un programme multi-services demande une structure différente et une phase d’arbitrage préalable.