Cahier des charges pour un projet d'automatisation IA : le guide PME 2026

Le cahier des charges (CDC) est le document qui cadre un projet d'automatisation IA. Trop long, il fige tout avant d'avoir testé. Trop vague, impossible de chiffrer. Voici la structure en 8 sections qui marche, validée sur 40 projets PME.

Pourquoi un CDC est-il utile (mais pas comme dans le BTP) ?

Un projet IA n'est pas un projet de construction où tout est figé d'avance. C'est un projet itératif : on teste, on calibre, on ajuste. Le CDC doit donc cadrer sans tout figer.

Ce qu'un CDC IA doit faire :

• Aligner client et prestataire sur le problème et les objectifs
• Permettre un chiffrage réaliste
• Définir le périmètre (éviter le scope creep)
• Fixer les critères de réception (savoir quand c'est "bon")

Ce qu'un CDC IA ne doit PAS faire :

• Spécifier chaque détail technique d'avance (ça se découvre en calibration)
• Figer des choix qui devraient émerger des tests
• Faire 40 pages que personne ne lira

Le bon CDC IA tient en 4-8 pages. Pour le contexte de cadrage, voir notre méthode pilote projet IA PME en 8 semaines.

Quelles sont les 8 sections d'un bon CDC IA ?

Structure validée sur 40 projets.

Section 1 — Contexte et problème quantifié

Décrire le contexte business et le problème à résoudre, chiffré. Pas "on perd du temps" mais "les commerciaux passent 60% de leur temps à trier des leads, soit ~5h/jour sur 8 commerciaux".

Section 2 — Objectifs et KPIs cibles

Ce qu'on veut atteindre, mesurable. Pas "améliorer la productivité" mais "réduire le temps de tri de 50%, augmenter les RDV qualifiés de 30%, sur 6 mois". Avec des valeurs cibles.

Section 3 — Périmètre précis

Ce qui est dans le projet ET ce qui en est exclu. La section la plus importante pour éviter le scope creep. Ex : "Inclus : qualification leads entrants Instagram. Exclu : prospection sortante, gestion des clients existants."

Section 4 — Données disponibles et accès

Quelles données existent, sous quelle forme, comment y accéder. C'est ce qui conditionne le plus le délai et la faisabilité. Ex : "Historique de 400 conversations dans GoHighLevel, accès API disponible."

Section 5 — Contraintes

RGPD, sécurité, secret professionnel, budget plafond, délai impératif. Tout ce qui borne le projet. Ex : "Données de santé, RGPD renforcé obligatoire, hébergement zone Europe."

Section 6 — Intégrations requises

Quels outils l'agent doit interroger ou alimenter (CRM, ERP, agenda, messagerie). Ex : "GoHighLevel (lecture/écriture), Calendly (création RDV), Instagram Business (réception messages)."

Section 7 — Critères de réception

Comment on saura que le projet est "réussi" et acceptable. Lié aux KPIs mais opérationnel. Ex : "Taux de résolution autonome > 75% sur 200 conversations test, CSAT > 4/5."

Section 8 — Gouvernance et maintenance

Qui pilote, qui maintient, à quelle fréquence on revoit. Souvent oublié, c'est ce qui fait durer le projet. Voir notre guide maintenance long terme agent IA en production.

Quels sont les pièges fréquents à éviter ?

Sur 40 projets, les pièges récurrents dans les CDC.

Piège 1 — Le CDC trop long et trop technique

Certaines PME (ou leurs DSI) produisent des CDC de 40 pages qui spécifient chaque détail technique. Résultat : ils figent des choix qui devraient émerger des tests, et personne ne les lit en entier. Le bon CDC IA est court et orienté problème/objectifs, pas solution technique.

Piège 2 — Le CDC trop vague

À l'inverse, un CDC d'une page "on veut un agent IA pour le SAV" ne permet pas de chiffrer ni de cadrer. Trop vague = devis impossible = projet qui dérape. Il faut le bon niveau de précision.

Piège 3 — Pas de problème quantifié

Sans chiffres sur le problème actuel, impossible de mesurer le ROI après. La quantification du problème (section 1) est non-négociable. Voir notre méthode mesurer le ROI d'un projet IA en PME.

Piège 4 — Périmètre flou

"L'agent gérera le SAV" sans préciser ce qui est inclus/exclu = scope creep garanti. Le client ajoute des demandes en cours de route, le projet dérape en délai et budget. Le périmètre explicite (section 3) protège les deux parties.

Piège 5 — Pas de critères de réception

Sans critères de réception clairs, le projet ne se "termine" jamais (toujours une amélioration à demander). Les critères de réception (section 7) définissent la ligne d'arrivée.

Comment quantifier le problème et les objectifs ?

La quantification est ce qui distingue un bon CDC d'un mauvais.

Pour quantifier le problème :

• Mesurer (chronométrer, compter), ne pas estimer au doigt mouillé
• Exprimer en euros, heures, volume, taux
• Ex : "16% de no-show sur 240 RDV/jour = ~26 créneaux perdus/jour = ~28K€/an de manque à gagner"

Pour quantifier les objectifs :

• Cibles chiffrées et datées
• Réalistes (basées sur des benchmarks ou des cas comparables)
• Ex : "Réduire le no-show à moins de 6% sous 6 mois"

Cette quantification sert ensuite de ligne de base pour mesurer le ROI. Sans elle, le projet marche peut-être mais ne se prouve pas. Pour le pattern complet, voir notre méthode mesurer le ROI d'un projet IA en PME.

Comment définir un périmètre qui n'explose pas ?

Le périmètre est la section qui sauve (ou tue) un projet.

Règle 1 — Lister explicitement ce qui est EXCLU

Aussi important que ce qui est inclus. "Inclus : X, Y. Exclu : Z, W." Ça coupe court aux demandes "tant qu'on y est" en cours de projet.

Règle 2 — Un seul cas d'usage principal au démarrage

Résister à la tentation de "couvrir 3 cas pendant qu'on y est". 1 cas d'usage bien fait > 3 cas bâclés. Les extensions viendront après validation. Voir notre méthode pilote projet IA PME en 8 semaines.

Règle 3 — Prévoir explicitement les évolutions futures

Plutôt que de tout vouloir dans la v1, lister les évolutions envisagées "pour plus tard" dans une section dédiée. Ça rassure le client (on n'oublie pas ses idées) sans alourdir la v1.

Règle 4 — Définir le "hors périmètre = avenant"

Acter que toute demande hors périmètre fera l'objet d'un avenant chiffré. Protège le délai et le budget des deux côtés.