Cahier des charges d'un projet IA : le modèle commenté pour une PME

Vous avez un usage en tête, un budget approximatif, et un prestataire qui réclame « un cahier des charges ». Trois semaines plus tard, le document existe, il fait douze pages, et personne ne sait dire ce qui sera livré ni comment on vérifiera que ça fonctionne. Le projet démarre quand même, sur une interprétation. C'est là que se creusent les écarts de périmètre, les reprises facturées en plus et les livrables que personne n'ose refuser.

Un cahier des charges de projet IA n'est pas un dossier technique. C'est un document de décision : il fixe le problème, le résultat attendu, les contraintes non négociables et la manière dont on constatera que le travail est fait. Il tient en deux à cinq pages, et il s'écrit avant de demander un prix.

Key Takeaways

• Un cahier des charges IA décrit un résultat et des critères d'acceptation, pas une solution technique : le choix de l'outil appartient au prestataire, le choix du problème appartient à l'entreprise.
• Sept blocs suffisent : contexte et objectif, périmètre inclus et exclu, données, résultat attendu et recette, contraintes, coûts et réversibilité, gouvernance.
• Le bloc le plus souvent bâclé est celui des données. Selon Gartner (2025), 63 % des organisations ne disposent pas, ou ignorent si elles disposent, des bonnes pratiques de gestion des données nécessaires à l'IA.
• Les critères d'acceptation s'écrivent avant le devis, sous forme de cas de test nommés. Sans eux, la livraison se juge à l'impression, et l'impression se discute.
• Le document se rédige en interne, avec l'équipe qui subit le problème. Un prestataire peut le challenger, pas le remplacer.

Un cahier des charges fixe un résultat, pas un outil

La tentation la plus fréquente en PME est de partir de l'outil. « On voudrait un agent IA branché sur WhatsApp qui trie les demandes. » La phrase décrit une intention et un canal, pas un résultat. Elle laisse au prestataire le soin de deviner ce qu'est une demande bien triée, à quelle vitesse, avec quel taux d'erreur acceptable, et qui corrige quand le tri se trompe.

Un projet IA se juge sur une chaîne de trois éléments : la qualité de la sortie, le temps gagné, et le coût de fonctionnement. Si le cahier des charges ne dit rien sur ces trois points, le prestataire livrera ce qu'il sait faire, dans le délai qu'il maîtrise, et la discussion sur la valeur arrivera trop tard.

Cette imprécision coûte cher. Dans une note publiée en juillet 2024, Gartner estimait qu'au moins 30 % des projets d'IA générative seraient abandonnés après la preuve de concept avant fin 2025, pour quatre raisons : qualité des données insuffisante, contrôles de risque inadaptés, coûts qui dérapent, valeur métier floue. Trois de ces quatre raisons se traitent dans le document que vous rédigez avant de signer.

La bonne question de départ n'est donc pas « quel outil ? » mais « quelle décision devient plus rapide, ou quel travail disparaît ? ». Une réponse à cette question tient en une phrase, et cette phrase devient la première ligne du cahier des charges. Si vous ne parvenez pas à l'écrire, le cadrage n'est pas terminé : c'est exactement le travail que couvre un audit de cadrage.

Les sept blocs du modèle, commentés

Le squelette ci-dessous fonctionne pour un agent conversationnel, une automatisation de back-office, un outil de tri de documents ou un modèle de prévision. Ce qui change d'un projet à l'autre, c'est le contenu, jamais la structure.

1. Contexte et objectif métier. Décrivez où le problème se manifeste, à quelle fréquence, et qui le subit. Mesurez la situation actuelle avec vos propres chiffres : nombre de demandes par semaine, temps de traitement moyen, taux d'erreur constaté. Ce bloc sert de point de comparaison à la recette. Sans mesure de départ, aucun gain ne sera démontrable, et le débat se déplacera sur des impressions.

2. Périmètre : ce qui est inclus et ce qui ne l'est pas. La colonne « exclu » est la plus importante, et c'est toujours celle qu'on oublie. Un projet IA déborde par nature : dès que l'agent trie les mails, quelqu'un demande qu'il y réponde, puis qu'il relance, puis qu'il mette à jour le CRM. Écrivez noir sur blanc les usages, les canaux et les langues qui restent hors du champ. Un périmètre exclu explicite vaut mieux qu'une liste d'inclusions généreuse.

3. Données et accès. Quelles données le système lira, où elles se trouvent, sous quel format, qui autorise l'accès, et pendant combien de temps elles sont conservées. Précisez la qualité attendue : champs obligatoires, doublons tolérés, documents scannés acceptés ou non. Ajoutez la question de l'anonymisation quand des données personnelles entrent dans le dispositif.

4. Résultat attendu et critères d'acceptation. Décrivez ce que voit l'utilisateur à la fin : un brouillon de réponse dans la boîte mail, une ligne ajoutée au tableur, une synthèse de rendez-vous. Puis listez les cas de test, en nommant chacun : demande simple, demande en langue étrangère, demande hors sujet, pièce jointe illisible, doublon client. Chaque cas reçoit un résultat attendu vérifiable. C'est le bloc qui transforme un projet en engagement.

5. Contraintes. Techniques (systèmes existants à ne pas remplacer, hébergement en Europe, débit pendant les pics), réglementaires (RGPD, secret professionnel, conservation des échanges) et humaines (qui valide chaque sortie avant envoi, qui utilise l'outil au quotidien, qui forme les nouveaux arrivants). Les contraintes humaines sont celles qui font échouer les projets les mieux cadrés techniquement.

6. Coûts, propriété et réversibilité. Distinguez le coût de construction des coûts récurrents : licences, consommation de modèles, hébergement, maintenance, corrections. Précisez à qui appartiennent les livrables, les prompts et les jeux de test. Enfin, écrivez la sortie : comment on récupère les données et la configuration si l'on change de prestataire ou si l'on arrête. Un projet IA sans clause de sortie devient une dépendance.

7. Gouvernance et recette. Nommez le décideur unique côté entreprise, la personne qui arbitre en cas de désaccord, et le calendrier de recette. Prévoyez la procédure en cas d'écart : nouvelle passe de correction, réduction de périmètre, ou arrêt. Un projet qui n'a pas de procédure d'arrêt n'a pas non plus de procédure de succès.

Si le projet produit un agent IA, ajoutez un bloc court sur le ton et les limites de réponse : ce que l'agent ne doit jamais dire, et vers qui il passe la main.

Cinq formulations à réécrire avant l'envoi

Un cahier des charges se relit en cherchant les phrases qu'un prestataire pourrait interpréter de deux façons. En voici cinq, avec leur version exploitable.

Les chiffres de ce tableau sont des exemples de formulation, à remplacer par vos engagements réels. L'intérêt n'est pas leur valeur exacte, c'est leur forme : un seuil, un cas, un délai, un responsable.

Les données : le bloc qui décide de la suite

La même étude Gartner citée plus haut chiffre le risque : toujours selon Gartner (2025), les organisations abandonneraient 60 % des projets d'IA non soutenus par des données prêtes pour l'IA d'ici 2026. Autrement dit, le modèle n'est presque jamais le point de rupture. Le point de rupture, c'est ce qu'on lui donne à lire.

En PME, cela se traduit par trois vérifications concrètes. D'abord, la disponibilité : les données existent-elles sous forme exploitable, ou faut-il d'abord sortir des PDF d'un logiciel métier ? Ensuite, la régularité : les champs sont-ils remplis de la même façon par toutes les équipes ? Enfin, la propriété : qui a le droit de faire circuler ces données vers un outil externe, et sous quelles conditions ?

Le manque d'expertise interne complique l'exercice. En 2025, 18 % des entreprises françaises de 10 salariés ou plus déclarent utiliser au moins une technologie d'IA, et parmi celles qui n'en utilisent aucune, 54 % citent un manque d'expertise, selon l'Insee (2026). Ce n'est pas un aveu de retard, c'est une information à intégrer au document : prévoyez qui sera capable de relire les sorties du système dans six mois, et ce que vous ferez si cette personne part.

Un cahier des charges honnête mentionne aussi ce que l'entreprise ne sait pas encore. Une phrase du type « la qualité des données historiques n'a pas été auditée » vaut mieux qu'une affirmation rassurante que le prestataire prendra au mot. Cette transparence se retrouve dans le prix.

Coûts, propriété et conditions de sortie

Le budget d'un projet IA se lit sur douze mois, pas sur la facture initiale. Trois postes reviennent : la construction, l'usage (consommation de modèles, licences, hébergement) et la maintenance. Demandez au prestataire de séparer les trois, et de préciser ce qui varie avec le volume. Un forfait construit sur une hypothèse de 500 demandes par mois ne tient pas si vous en traitez 3 000.

La propriété mérite une clause explicite. Les prompts, les jeux de test, la documentation et les scripts d'intégration doivent être listés comme livrables. Sans cette liste, un changement de prestataire se traduit par une reconstruction complète, souvent au prix fort. La clause de sortie est le pendant de cette exigence : format des données exportées, délai de remise, suppression des copies détenues par le prestataire.

Ce travail de rédaction rejoint celui du devis, et souvent les deux documents se répondent. Pour vérifier que les deux versions racontent la même chose, ce qu'un devis d'agent IA doit contenir donne une grille de lecture utile.

Qui l'écrit, et en combien de temps

Le cahier des charges s'écrit côté entreprise, par le dirigeant ou le responsable métier concerné, avec les personnes qui vivent le problème au quotidien. Un consultant peut animer l'exercice, poser les questions et reformuler, mais il ne peut pas inventer vos contraintes. Quand le document arrive entièrement rédigé par le prestataire, l'entreprise achète une solution sans avoir défini son besoin.

Comptez deux à cinq jours de travail répartis sur deux semaines, dont l'essentiel en entretiens courts : une heure avec l'équipe qui subit le problème, une heure avec la personne qui détient les données, une heure avec celle qui paiera la facture et qui doit donc arbitrer. Le document final tient en deux à cinq pages. Au-delà de huit pages, il décrit l'architecture à la place du prestataire et devient un cahier de négociation.

Le bon moment pour l'écrire est avant la consultation, pas après. Un document rédigé après le devis sert à justifier une décision déjà prise. Pour situer ce travail dans la séquence complète, les six étapes d'un projet IA montre où le cadrage se place, et pourquoi il conditionne la suite.

FAQ

Combien de pages doit faire un cahier des charges IA ?

Deux à cinq pages pour un projet de PME, hors annexes techniques. L'annexe peut contenir les schémas de données, la liste des cas de test et les exemples de documents. Le corps du document doit rester lisible par un dirigeant en vingt minutes, sinon il ne sera pas relu au moment des arbitrages.

Faut-il nommer l'outil dans le document, par exemple ChatGPT ou n8n ?

Nommez un outil seulement s'il s'agit d'une contrainte réelle : un système déjà en place, un accord-cadre, une obligation d'hébergement. Sinon, décrivez la fonction attendue et les contraintes, puis laissez le prestataire proposer. Cette liberté est ce qui vous permet de comparer deux offres sur le résultat plutôt que sur une marque.

Mon prestataire affirme que rédiger le cahier des charges fait partie de sa mission. Qui a raison ?

Les deux, à condition de séparer les rôles. Le prestataire est légitime pour rédiger la spécification technique, l'architecture et le plan de tests. L'entreprise reste propriétaire de l'objectif, du périmètre, des critères d'acceptation et du budget. Un prestataire qui refuse de discuter de ces quatre points avant de chiffrer prend le contrôle du projet.

Un cahier des charges garantit-il que le projet réussira ?

Non. Il réduit les écarts d'interprétation, il rend la recette opposable, et il oblige à formuler les cas limites avant de payer. Il ne remplace ni la qualité des données, ni la disponibilité des équipes, ni la décision d'arrêter un projet qui ne tient pas ses critères. C'est un instrument de pilotage, pas une assurance.

Que faire si aucun prestataire ne répond point par point au document ?

Considérez le silence comme une information. Soit le périmètre reste trop vague pour être chiffré, soit le prestataire ne souhaite pas s'engager sur des critères mesurables. Dans les deux cas, envoyer le document à un troisième prestataire coûte moins cher que signer une réponse partielle. Si vous voulez automatiser des tâches répétitives sans passer par un projet IA complet, le cadrage reste le même, avec un périmètre plus court.

Conclusion

Un cahier des charges de projet IA sert à trois choses : décider ce que l'on veut, rendre la livraison vérifiable, et garder la main sur la sortie. Les sept blocs du modèle tiennent sur deux pages, et la plupart des dérapages observés viennent de blocs laissés vides, pas de choix techniques discutables.

Si vous préparez un projet et que le document n'existe pas encore, commencez par la phrase d'objectif et par vos propres mesures de départ. Si le document existe mais qu'il vous paraît flou, faites-le relire avant l'envoi : nous écrire suffit pour obtenir un avis sur les points qui manquent.