Cahier des charges projet IA pour une PME : modèle et méthode

Vous avez identifié un cas d'usage IA dans votre entreprise. Vous êtes prêt à consulter des prestataires. Avant d'envoyer vos premiers emails, il vous faut un cahier des charges projet IA structuré. Pas pour couvrir vos arrières, mais parce qu'un document bien préparé change radicalement la qualité des réponses que vous recevrez.

Chez Tensoria, on reçoit des dizaines de demandes par an. On voit la différence immédiatement entre un dirigeant qui arrive avec un document clair et un autre qui envoie deux lignes vagues. Le premier obtient des propositions précises et comparables. Le second reçoit des devis qui ne se ressemblent pas, sur des périmètres différents, impossible à évaluer sérieusement.

Ce guide vous donne la structure opérationnelle d'un CDC IA pour PME : pourquoi il diffère d'un cahier des charges informatique classique, ce qu'il doit contenir, les erreurs qui sabotent les consultations, et les vraies questions à poser aux prestataires avant de signer.

Si vous n'avez pas encore identifié précisément votre cas d'usage, commencez par notre guide sur l'audit IA en PME avant de rédiger quoi que ce soit.

Pourquoi un cahier des charges IA n'est pas un cahier des charges SI classique

Un cahier des charges pour un ERP ou un site web peut décrire précisément les fonctionnalités attendues, les flux de données, les règles de gestion. On sait ce qu'on veut, on demande à un prestataire de le construire. Le résultat est déterministe.

Un projet IA, c'est différent sur quatre points fondamentaux.

L'incertitude sur les performances est structurelle

Quand vous commandez un module de facturation, vous savez qu'il calculera correctement la TVA. Quand vous commandez un système d'extraction automatique de clauses dans vos contrats, personne ne peut vous promettre un taux de précision exact avant d'avoir testé sur vos données réelles. Les modèles d'IA ont des performances qui varient selon la qualité, le volume et la représentativité des données. C'est la nature même de la technologie.

Conséquence pour votre CDC : vous devez prévoir une phase de validation sur données réelles (POC) et définir vos critères d'acceptation en termes opérationnels, pas en termes de métriques abstraites.

Les données sont le vrai capital, pas le code

Dans un projet SI, les données sont un input. Dans un projet IA, les données sont la matière première de la solution. Un modèle entraîné sur des données de mauvaise qualité produira des résultats de mauvaise qualité, peu importe la sophistication du code. La qualité de votre CDC IA dépend en grande partie de votre capacité à décrire vos données : leur volume, leur format, leur état de structuration, leur historique.

La démarche est itérative, pas linéaire

Un projet SI classique suit un plan : specs, développement, recette, déploiement. Un projet IA s'affine par itérations. La première version du modèle ne sera pas la bonne. Les équipes terrain feront remonter des cas que le système gère mal. Il faudra ajuster, réentraîner, améliorer. Votre CDC doit prévoir cette réalité et ne pas exiger un résultat parfait dès la livraison initiale.

Le ROI se mesure différemment

Un ERP a un coût d'achat et un ROI calculé sur les gains de productivité opérationnels. Un projet IA a un ROI plus complexe à mesurer : il faut inclure le coût de maintenance continue, les gains indirects (qualité, réduction d'erreurs, libération de temps qualifié), et la valeur stratégique à long terme. Votre CDC doit poser les bases de cette mesure dès le début.

Structure type d'un cahier des charges IA pour une PME

Un CDC IA PME efficace n'a pas besoin d'être un roman. Entre 8 et 15 pages, bien structurées, suffisent pour obtenir des propositions sérieuses et comparables. Voici les sections indispensables.

• Section 1 : contexte de l'entreprise et problème métier à résoudre
• Section 2 : périmètre du projet, livrables attendus et critères d'acceptation
• Section 3 : données disponibles, contraintes RGPD et souveraineté
• Section 4 : budget indicatif, planning souhaité et gouvernance post-projet
• Annexes : exemples de documents, captures d'écran, exemples de cas à traiter

Ce qui manque dans 80% des CDC que nous recevons : la section sur les données et la section sur la gouvernance. Ce sont pourtant les deux qui font le plus la différence entre un projet qui réussit et un projet qui s'enlise.

Section 1 : contexte métier et problème à résoudre

C'est la section la plus importante. Un prestataire IA compétent lit d'abord cette section avant toute autre chose. Si elle est vague, le reste du CDC ne sert à rien.

Ce que cette section doit contenir

Présentez votre entreprise en 3 à 5 lignes : secteur, taille, activité principale. Puis décrivez le problème que vous cherchez à résoudre en termes opérationnels concrets. Pas "améliorer notre productivité", mais :

• "Notre équipe commerciale passe en moyenne 3 heures par semaine à lire et trier les réponses aux appels d'offres reçus par email pour évaluer si on répond ou non. Nous voulons automatiser cette qualification initiale."
• "Nos techniciens remplissent des rapports de maintenance manuellement après chaque intervention. La saisie prend 45 minutes par rapport. Nous voulons générer un premier jet à partir de leurs notes vocales."

Décrivez également le processus actuel pas à pas : qui fait quoi, avec quels outils, à quelle fréquence, quel est le volume traité par semaine ou par mois. Ce niveau de détail permet à un prestataire d'évaluer la complexité réelle du projet dès la lecture du CDC.

Précisez le contexte de décision

Indiquez si vous avez déjà réalisé un audit IA, si vous avez déjà consulté d'autres prestataires, ce qui vous a bloqué jusqu'ici. Ces éléments de contexte évitent les redites et montrent que vous avez déjà réfléchi au sujet. Ils donnent aussi au prestataire des éléments pour calibrer sa proposition.

Section 2 : périmètre, livrables et critères d'acceptation

C'est la section où les malentendus se créent le plus souvent entre un client et un prestataire IA. Soyez précis sur ce que vous voulez, et explicite sur ce que vous ne voulez pas.

Définir le périmètre sans sur-spécifier la technologie

Décrivez ce que le système doit faire fonctionnellement. Ne prescrivez pas la technologie sauf si vous avez une contrainte réelle (hébergement sur votre infrastructure, intégration avec un outil spécifique). Évitez les formules du type "nous voulons un LLM fine-tuné sur nos données" si vous n'avez pas la certitude que c'est la bonne approche. Laissez le prestataire proposer l'architecture. C'est son métier.

En revanche, soyez précis sur :

• Les entrées du système : quel type de documents, emails, fichiers, flux de données
• Les sorties attendues : une note de synthèse, un fichier structuré, une classification, une alerte
• Les intégrations obligatoires : connexion à votre CRM, votre ERP, votre messagerie
• Le niveau d'autonomie souhaité : le système décide seul ou soumet à validation humaine

Les livrables : ce que vous payez

Listez les livrables attendus à chaque étape. Pour un projet IA, les livrables typiques incluent :

• Un rapport de faisabilité technique après analyse de vos données (avant le développement)
• Une version POC testée sur un échantillon représentatif de vos données réelles
• La solution déployée en production avec documentation d'utilisation
• Un tableau de bord de suivi des performances (taux de traitement automatique, taux d'erreur)
• Un plan de maintenance et de mise à jour du modèle

Les critères d'acceptation : le vrai contrat de résultat

C'est la partie que presque tous les CDC PME oublient, et c'est celle qui protège le plus les deux parties. Définissez des critères mesurables sur des données réelles, pas sur des datasets synthétiques.

Exemple concret : au lieu de "précision supérieure à 95%", écrivez "le système traite correctement au moins 85% des cas d'un lot de 300 documents représentatifs de notre activité réelle, sans intervention humaine". Ajoutez des critères de performance (temps de traitement), de fiabilité (comportement en cas d'erreur), et d'adoption (taux d'utilisation par les équipes après 30 jours).

Prévoyez aussi une clause de révision à 3 mois : les premières semaines en production font remonter des cas que le POC n'avait pas couverts. C'est normal. Intégrez-le dans votre contrat.

Section 3 : données disponibles, RGPD et souveraineté

C'est la section la plus sous-estimée. Elle conditionne pourtant la faisabilité du projet. Un prestataire sérieux vous posera de toute façon ces questions. Autant anticiper.

Décrivez vos données avec précision

Pour chaque source de données, précisez :

• La nature : emails, PDFs, tableaux Excel, données CRM, notes manuscrites scannées
• Le volume : combien de documents par mois, depuis combien d'années
• L'état : structuré, semi-structuré, non structuré ; annoté ou brut ; en français, en anglais, multilingue
• La qualité : documents scannés avec mauvaise résolution, formats hétérogènes, données incomplètes
• L'accessibilité : données disponibles immédiatement, nécessitant une extraction depuis un ERP, nécessitant un nettoyage préalable

Cette description permet au prestataire d'évaluer si un modèle peut être entraîné ou affiné sur vos données, ou si une approche RAG (Retrieval-Augmented Generation) est plus adaptée.

Contraintes RGPD et souveraineté des données

Indiquez clairement le niveau de sensibilité de vos données. Pour chaque catégorie de données impliquée dans le projet :

• S'agit-il de données à caractère personnel au sens RGPD ?
• S'agit-il de données confidentielles (savoir-faire, données financières, données clients sensibles) ?
• Avez-vous des obligations sectorielles (secret médical, secret des affaires, données classifiées) ?

Précisez ensuite vos exigences de localisation : hébergement exclusivement en France, en UE, ou acceptation d'un hébergement US avec pseudonymisation préalable. Si vous avez des contraintes de souveraineté fortes, mentionnez-le explicitement. Des solutions comme les architectures souveraines avec Mistral existent et permettent de traiter des données sensibles sans les envoyer sur des serveurs étrangers.

Demandez systématiquement un DPA (Data Processing Agreement) au prestataire et précisez que vos données ne doivent pas servir à réentraîner des modèles tiers. Un prestataire sérieux proposera cette clause sans que vous ayez à l'exiger.

Section 4 : budget, planning et gouvernance

Indiquer un budget, même indicatif

Beaucoup de dirigeants hésitent à indiquer un budget dans leur CDC, craignant que le prestataire s'y cale automatiquement. C'est une erreur. L'absence de budget force les prestataires à proposer des périmètres différents, rendant la comparaison impossible.

Indiquez une fourchette réaliste. Pour vous aider à calibrer : un projet d'automatisation simple se situe entre 5 000 et 20 000 €. Un projet métier plus complexe (assistant RAG, analyse de documents structurés) entre 15 000 et 50 000 €. Notre guide sur les coûts de projet IA pour PME détaille ces fourchettes par type de projet.

Séparez dans votre budget :

• Le budget de développement et déploiement (coût fixe, one-shot)
• Le budget de fonctionnement (APIs, hébergement, coûts variables mensuels)
• Le budget de maintenance et d'évolution (souvent oublié, pourtant critique)

Un planning réaliste

Indiquez votre contrainte de délai si vous en avez une (événement commercial, audit prévu, fin d'un contrat existant). Précisez aussi votre disponibilité interne : combien de jours par mois pouvez-vous mobiliser un référent métier pour les ateliers de cadrage, les tests et les validations ? Un prestataire a besoin de votre temps, pas seulement de votre budget.

Attendez-vous aux délais suivants pour un projet de taille standard :

• Cadrage et analyse des données : 2 à 3 semaines
• Développement du POC : 3 à 6 semaines
• Validation et ajustements : 2 à 3 semaines
• Déploiement en production : 1 à 2 semaines

La gouvernance après le projet

C'est la section la plus fréquemment absente des CDC, et l'une des plus importantes pour la valeur à long terme. Un modèle IA non maintenu se dégrade. Les données changent, les processus évoluent, les performances baissent. Précisez dans votre CDC :

• Qui est responsable du suivi des performances en interne (un référent nommé) ?
• Quelle fréquence de mise à jour du modèle souhaitez-vous (mensuelle, trimestrielle) ?
• Souhaitez-vous un contrat de maintenance avec le prestataire ou une reprise en interne ?
• Quelle est votre exigence de documentation pour permettre une reprise par un tiers ?

Ces questions posées dès le CDC évitent de vous retrouver captif d'un prestataire unique pour la moindre évolution du système.

Les erreurs classiques qui sabotent un CDC IA

Après avoir reçu et traité des dizaines de consultations, voici les erreurs qui reviennent systématiquement.

Sur-spécifier la technologie au lieu du besoin

C'est l'erreur numéro un. Un CDC qui demande "un LLM fine-tuné sur GPT-4 avec une interface React" avant même d'avoir décrit le problème métier est un CDC qui orientera les prestataires vers une solution pré-choisie, pas vers la meilleure solution. Décrivez ce que vous voulez obtenir, pas comment vous pensez qu'on devrait le construire. Le choix technologique doit venir après l'analyse de votre contexte réel, pas avant.

Oublier de décrire les données

Un CDC qui dit "nous avons des données" sans les décrire oblige chaque prestataire à poser les mêmes questions lors du premier rendez-vous. Vous perdez du temps. Pire : certains prestataires découvrent en cours de projet que les données ne sont pas exploitables en l'état (mauvaise qualité, volume insuffisant, format inutilisable). Le projet s'arrête, le budget est consommé. Investissez 2 heures pour décrire précisément vos sources de données. Cela vous économisera des semaines.

Demander un POC sans budget de mise en production

C'est le piège classique du "on teste, et on verra". Un POC coûte de l'argent. Un déploiement en production coûte plus. Si votre budget total est de 10 000 € et que vous en dépensez 8 000 € sur le POC, vous n'aurez pas les moyens de déployer. Dès le CDC, prévoyez un budget qui couvre les deux phases. Sinon vous vous retrouvez avec un prototype qui fonctionne dans les conditions du test mais que personne n'utilise au quotidien.

Fixer des critères d'acceptation irréalistes

Exiger "100% de précision" ou "zéro erreur" dans un projet IA révèle une méconnaissance de la technologie. Tous les systèmes d'IA font des erreurs. La question pertinente n'est pas "combien d'erreurs ?", c'est "quel niveau d'erreur est acceptable opérationnellement ?". Un prestataire qui accepte des critères à 100% sans broncher est soit malhonnête, soit incompétent.

Ne pas prévoir la maintenance dans le budget

Un système IA sans maintenance se dégrade avec le temps : les données changent, les formats évoluent, les comportements utilisateurs s'adaptent. Prévoyez dans votre budget une enveloppe de maintenance annuelle, généralement entre 15% et 25% du coût de développement initial. Un prestataire qui vous propose un projet "clé en main sans coût ultérieur" vous vend quelque chose qui ne fonctionnera plus dans 18 mois.

Les vraies questions à poser aux prestataires IA

Le CDC attire les prestataires. Le premier entretien vous permet de les évaluer. Voici les questions qui révèlent la qualité réelle d'un prestataire IA, au-delà du discours commercial.

Sur la faisabilité et les données

• "Après lecture de notre CDC, quels sont vos doutes sur la faisabilité ?" Un bon prestataire identifie des risques et les formule clairement. Un mauvais prestataire vous dit que tout est faisable sans nuance.
• "Avez-vous besoin d'analyser nos données réelles avant de faire une proposition ferme ?" La réponse honnête est presque toujours oui pour un projet métier complexe.
• "Quel volume de données vous semble nécessaire pour obtenir des résultats acceptables ?"

Sur la méthode et les engagements

• "Comment définissez-vous les critères d'acceptation du POC ?" Le prestataire doit parler de métriques opérationnelles, pas uniquement techniques.
• "Que se passe-t-il si le POC n'atteint pas les critères d'acceptation ?" Cherchez un prestataire qui prévoit des clauses de sortie claires.
• "Montrez-moi un exemple de projet similaire au nôtre que vous avez déployé en production." Le mot clé est "production". Les POC non déployés ne comptent pas.

Sur la gouvernance et la pérennité

• "Comment est documenté le système pour permettre une reprise par un tiers ?"
• "Qui maintient le modèle si vos données évoluent dans 12 mois ?"
• "Quelles sont vos pratiques de conformité RGPD et AI Act pour ce type de projet ?" La conformité à l'AI Act est une réalité réglementaire en 2026. Un prestataire qui découvre le sujet lors de votre question est un signal d'alerte.

Sur la relation commerciale

• "Quelle part du budget prévoyez-vous pour la maintenance dans les 12 premiers mois ?"
• "Qui sera l'interlocuteur technique sur ce projet au quotidien ?" Vérifiez que c'est bien la personne compétente que vous rencontrez, et non un commercial qui passera le relais à une équipe distante.

Si vous cherchez comment choisir une agence IA, notre article dédié complète ce point de vue avec des critères de sélection approfondis.

Questions fréquentes

Pour aller plus loin

• Audit IA PME en 2026 : méthode, coût et livrables concrets — à lire avant de rédiger votre CDC si vous n'avez pas encore identifié vos cas d'usage
• Lancer un projet IA en entreprise : le guide réaliste — pour comprendre les deux types de projets et choisir le bon premier pas
• Combien coûte un projet IA en 2026 : budgets et postes de coûts — pour calibrer votre enveloppe budgétaire avant consultation
• Comment choisir une agence IA à Toulouse — les critères de sélection qui comptent vraiment
• ROI des projets IA : comment mesurer la valeur réelle — pour construire votre business case interne avant de consulter
• RAG : comprendre l'architecture qui alimente la plupart des projets IA métier — pour ne pas être perdu quand les prestataires parlent technique
• 5 erreurs qui font échouer vos projets RAG en entreprise — les pièges à anticiper dans votre CDC
• AI Act : guide de conformité pour les PME — les exigences réglementaires à intégrer dans votre CDC dès maintenant