Comment rédiger un cahier des charges pour un projet d'agent IA ?

Un DG signe un devis pour « un agent IA qui traite les demandes clients ». Trois mois plus tard, personne ne sait dire si le projet a réussi. Le prestataire a livré quelque chose qui répond à des emails. Le service client constate qu'il doit tout relire. La DSI découvre que l'agent accède à une boîte partagée dont elle ignorait l'existence. Le problème ne vient pas de la technologie. Il vient d'un cahier des charges qui n'a jamais existé, ou qui tenait en trois lignes.

Rédiger un cahier des charges pour un agent IA ne ressemble pas à rédiger celui d'un logiciel classique. Un agent interprète, décide, agit sur vos systèmes. Il faut donc cadrer ce qu'il fait, mais aussi ce qu'il ne fait pas, avec quelles données, et sous quel contrôle. Voici les cinq blocs à traiter, dans l'ordre.

1. Le périmètre : ce que l'agent fait, et ce qu'il ne fait pas

Commencez par une phrase simple : « L'agent prend en charge X, à partir de Y, pour produire Z. » Si vous ne parvenez pas à l'écrire en une phrase, le périmètre est trop flou.

Ensuite, écrivez les exclusions. C'est la partie la plus négligée et la plus utile. Un agent qui relance les factures en retard doit-il aussi traiter les litiges ? Gérer les clients en procédure collective ? Répondre aux clients qui contestent ? Chaque exclusion non écrite devient un cas limite que l'agent traitera à sa façon.

• Périmètre inclus : les cas, les volumes attendus, les types de documents ou de demandes.
• Périmètre exclu : les cas transmis à un humain, les clients ou fournisseurs sensibles, les montants au-delà d'un seuil.
• Frontières : à quel moment l'agent s'arrête et à qui il transmet.

Pour choisir un premier périmètre raisonnable, notre article sur les critères d'un premier cas d'usage agentique détaille les points à examiner.

2. Le processus concerné : décrire le réel, pas le théorique

Le cahier des charges doit s'appuyer sur le processus tel qu'il se déroule vraiment, avec ses contournements, ses exceptions et ses validations informelles. Le processus documenté dans le manuel qualité et celui que vos équipes pratiquent diffèrent presque toujours.

Pour chaque étape, notez qui fait quoi, avec quel outil, quelle règle s'applique et quelles exceptions existent. C'est ici que l'on se heurte à une vérité simple : on ne peut pas automatiser le chaos. Si deux collaborateurs traitent le même cas de deux manières différentes, l'agent héritera de l'ambiguïté. Il faut trancher avant, pas après. Notre article on ne peut pas automatiser le chaos détaille par où commencer, et la cartographie BPMN sur le terrain donne une méthode pour documenter l'existant.

3. Les données : quoi, où, dans quel état

Un agent ne vaut que par les informations auxquelles il accède. Listez pour chaque donnée :

• sa source (ERP, CRM, messagerie, fichiers partagés, base documentaire) ;
• son niveau de fiabilité et de mise à jour ;
• son propriétaire dans l'entreprise ;
• son niveau de sensibilité (données personnelles, financières, commerciales) ;
• les droits d'accès strictement nécessaires : lecture seule, écriture, suppression.

Appliquez le principe du moindre privilège : l'agent n'a accès qu'à ce dont il a besoin. Nous l'expliquons dans accès minimaux pour agents IA. Précisez aussi l'hébergement et la localisation des données : c'est un point de conformité autant que de confiance (voir pourquoi héberger vos agents en France). Enfin, évaluez honnêtement la qualité de vos données ; c'est le carburant invisible de vos agents.

4. Les critères de réussite : définis avant le démarrage

« Gagner du temps » n'est pas un critère. Un bon critère se mesure, a une valeur de départ et un horizon. Avant de lancer le projet, relevez la situation actuelle : temps de traitement, taux d'erreur, délais, charge de l'équipe. Sans cette base, personne ne pourra démontrer un gain, ni le contester.

Distinguez trois familles :

• Performance : délai de traitement, volume absorbé, taux de cas traités sans reprise humaine.
• Qualité : taux d'erreur, taux de corrections par l'équipe, conformité aux règles.
• Adoption : usage réel par les équipes, retours des opérateurs, cas remontés.

Fixez aussi un critère d'arrêt : à quel seuil de dégradation suspend-on l'agent ? Pour le suivi dans la durée, voir les indicateurs à regarder chaque semaine.

5. Les niveaux de supervision : qui contrôle, quand, comment

C'est le bloc qui distingue un projet tenable d'un projet risqué. Pour chaque type d'action, décidez du niveau d'autonomie :

• Proposition : l'agent prépare, l'humain valide chaque action.
• Exécution contrôlée : l'agent agit, l'humain vérifie par échantillonnage.
• Autonomie encadrée : l'agent agit seul dans des limites définies (montant, type de cas), avec alertes en cas d'écart.

Dans un premier temps, on démarre presque toujours au niveau le plus prudent, puis on monte progressivement selon les résultats observés. Cette logique est détaillée dans human-in-the-loop et le plan de montée en autonomie. Prévoyez aussi les journaux d'activité, les alertes et la possibilité de révoquer l'agent à tout moment (les fondamentaux de l'observabilité).

Un scénario hypothétique : le traitement des demandes de devis

Prenons une PME de négoce fictive dont les commerciaux passent une part importante de leur semaine à préparer des devis récurrents à partir de demandes reçues par email.

Un cahier des charges médiocre dirait : « Automatiser les devis avec une IA. » Un cahier des charges structuré dirait :

• Périmètre : devis standards sur catalogue, hors produits sur mesure et hors clients en renégociation de contrat.
• Processus : réception de l'email, identification du client, vérification des tarifs dans l'ERP, génération du devis, envoi.
• Données : tarifs de l'ERP en lecture seule, historique client du CRM, aucun accès à la comptabilité.
• Réussite : délai de réponse comparé à la situation de départ, taux de devis corrigés par les commerciaux.
• Supervision : validation humaine systématique le premier mois, puis échantillonnage si la qualité est stable.

Cet exemple est volontairement simple, mais il montre l'essentiel : le projet est évaluable, borné et réversible.

Structurer avant d'automatiser

Écrire ce cahier des charges oblige à répondre à des questions que l'organisation évitait : qui décide en cas d'exception, quelle donnée fait foi, quelle règle prévaut. Ces réponses ont de la valeur au-delà du projet. Elles rapprochent l'entreprise de ce que nous appelons une organisation requêtable : une organisation dont les règles, les données et les responsabilités sont assez claires pour qu'un agent, comme un nouvel arrivant, puisse les exploiter.

Beaucoup d'échecs viennent d'un cadrage sauté, comme le montre notre analyse des projets IA qui échouent. Pour la suite, comment déployer un agent IA dans son entreprise décrit le passage à la mise en œuvre.