Cahier des charges IA pour PME : modèle et méthode
Un projet d’intelligence artificielle échoue rarement parce que le modèle n’est pas assez puissant. Il échoue parce que le besoin reste flou, que les données sont mal définies ou que personne ne sait dire si le résultat est acceptable. Un cahier des charges IA pour PME évite ces angles morts avant de comparer des éditeurs, des agences ou des solutions internes.
Un cahier des charges IA pour PME est un document de décision qui décrit le processus à améliorer, les données autorisées, le résultat attendu, les contrôles humains, les contraintes techniques et les critères de réussite mesurables. Il ne doit pas imposer une technologie trop tôt. Son rôle est de permettre à plusieurs prestataires de chiffrer le même périmètre et à l’entreprise de réceptionner un système réellement utilisable.
Commencer par le problème métier, pas par l’outil
« Nous voulons utiliser l’IA » n’est pas un besoin exploitable. Le point de départ doit être une tâche observée : qualifier des demandes entrantes, extraire les lignes de bons de commande, préparer un compte rendu, repérer des anomalies ou proposer une première réponse au support.
Décrivez le fonctionnement actuel avec cinq éléments :
- le déclencheur du processus ;
- les personnes qui interviennent ;
- les logiciels et documents utilisés ;
- le volume moyen et les pics d’activité ;
- les erreurs, délais ou coûts à réduire.
Ajoutez une mesure de départ. Par exemple : 600 demandes par mois, 7 minutes de traitement moyen, 8 % de dossiers réaffectés et un délai de première réponse de 18 heures. Sans cette référence, le gain annoncé après le déploiement restera une impression.
Le périmètre doit aussi dire ce qui ne sera pas automatisé. Une première version peut classer et préparer une réponse sans jamais l’envoyer seule. Cette frontière protège le projet contre la tentation d’ajouter des cas particuliers pendant la réalisation.
Les 10 rubriques d’un cahier des charges IA
Un document utile tient souvent entre cinq et quinze pages, annexes exclues. Les dix rubriques suivantes suffisent pour cadrer la majorité des projets d’une TPE ou d’une PME.
1. Contexte et objectif
Présentez l’entreprise, l’équipe concernée et la raison du projet. Formulez un objectif mesurable et daté : « réduire de 40 % le temps de qualification des demandes sous trois mois, sans augmenter le taux d’erreur » est plus utile que « gagner en productivité grâce à l’IA ».
2. Utilisateurs et responsabilités
Identifiez le sponsor, le responsable métier, l’administrateur et les utilisateurs quotidiens. Précisez qui valide les réponses, qui traite les exceptions et qui peut modifier les règles ou les instructions données au modèle.
3. Processus cible
Décrivez le flux étape par étape, de l’événement d’entrée jusqu’à l’archivage du résultat. Pour chaque étape, distinguez ce qui relève d’une règle fixe, d’un traitement IA et d’une validation humaine. Un schéma simple évite beaucoup d’ambiguïtés lors du chiffrage.
4. Données d’entrée et de sortie
Listez les sources : e-mails, CRM, ERP, tableurs, PDF, base documentaire ou formulaires. Pour chacune, indiquez le format, le propriétaire, la fréquence de mise à jour, la qualité observée et les droits d’accès. Définissez ensuite la sortie attendue avec un exemple concret : catégorie, score, résumé, brouillon ou données structurées.
5. Règles métier et cas limites
Documentez les règles qui ne doivent pas être devinées par le modèle : seuils, priorités, clients sensibles, langues acceptées, pièces obligatoires et motifs de rejet. Ajoutez les cas limites connus, comme un document illisible, une demande contradictoire ou une information absente.
6. Contrôle humain
Indiquez les actions que le système peut exécuter seul et celles qui exigent une approbation. Plus la conséquence d’une erreur est forte, plus le contrôle doit intervenir tôt. Un brouillon commercial peut être relu avant envoi ; une décision concernant un paiement, un recrutement ou un engagement contractuel ne doit pas reposer sur une réponse non contrôlée.
7. Intégrations et contraintes techniques
Nommez les systèmes à connecter, les environnements disponibles et les modes d’accès réellement autorisés : API, webhook, export programmé ou dépôt de fichier. Précisez les exigences d’authentification, de journalisation, de sauvegarde et de reprise après erreur. Une intégration non documentée peut représenter davantage de travail que la partie IA elle-même.
8. Sécurité et confidentialité
Classez les données manipulées : publiques, internes, confidentielles ou personnelles. Demandez où elles transitent, où elles sont stockées, combien de temps elles sont conservées et si elles peuvent servir à entraîner un service tiers. Définissez les accès par rôle, la suppression des données et la conduite à tenir en cas d’incident. Les engagements du prestataire devront être traduits dans le contrat, pas seulement présentés pendant la démonstration.
9. Mesure de la qualité et de la performance
Fixez des indicateurs compréhensibles par l’équipe métier : taux de réponses correctes, taux d’escalade, temps économisé, délai de traitement, coût par dossier et disponibilité. Pour une tâche de classement, mesurez chaque catégorie importante au lieu de vous contenter d’une moyenne générale qui peut masquer les erreurs rares mais graves.
10. Livrables, calendrier et budget
Listez les livrables attendus : prototype, connecteurs, paramétrage, documentation, jeu de tests, formation, tableau de bord, procédure de secours et transfert de compétences. Séparez le coût de mise en place des coûts récurrents : licences, consommation des modèles, hébergement, maintenance et support.
Le modèle prêt à remplir
La trame suivante peut être copiée dans un document de travail puis complétée avec les responsables concernés.
| Rubrique | Questions à renseigner |
|---|---|
| Problème actuel | Quelle tâche pose problème ? À quelle fréquence ? Quel coût ou quel délai aujourd’hui ? |
| Objectif | Quel résultat mesurable doit être atteint, pour quelle date ? |
| Périmètre | Quelles équipes, quels cas d’usage et quelles exclusions ? |
| Utilisateurs | Qui utilise, valide, administre et arbitre les exceptions ? |
| Entrées | Quelles données, quels formats, quels volumes et quelle qualité ? |
| Sorties | Quel résultat précis, dans quel outil et sous quel format ? |
| Règles | Quelles règles fixes, quels seuils et quels cas limites ? |
| Validation | Quand une intervention humaine est-elle obligatoire ? |
| Intégrations | Quels logiciels, API, comptes techniques et environnements ? |
| Sécurité | Quelles données sensibles, quels droits, quelle conservation ? |
| Recette | Sur quel jeu de tests et avec quels seuils d’acceptation ? |
| Exploitation | Qui surveille, corrige, documente et paie les coûts récurrents ? |
| Planning | Quelles étapes, dépendances et dates de décision ? |
| Budget | Quel plafond initial et quel budget mensuel d’exploitation ? |
Joignez trois à dix exemples réels anonymisés pour chaque cas important. Un exemple d’entrée accompagné de la sortie attendue vaut mieux qu’une longue description abstraite. Ajoutez aussi des exemples qui doivent être refusés ou transmis à un humain.
Comment définir une recette vérifiable
La recette ne doit pas se limiter à une démonstration préparée par le prestataire. Constituez avant le développement un jeu de cas représentatif, séparé des exemples utilisés pour régler la solution. Il doit contenir des cas simples, des cas ambigus, des données incomplètes et des situations à risque.
Pour chaque cas, notez le résultat attendu et la marge de tolérance. Une recette solide combine quatre familles de critères :
- qualité métier : résultat correct ou utile selon une grille définie ;
- robustesse : comportement prévu face aux données manquantes et aux pannes ;
- performance : délai de réponse et capacité à absorber les pics ;
- exploitabilité : journal compréhensible, alerte, reprise manuelle et traçabilité.
Exemple pour un système qui classe des e-mails clients : au moins 92 % de classement correct sur le jeu de recette, 100 % des messages liés à un litige transmis à un humain, aucun envoi automatique, traitement en moins de deux minutes et journalisation de la catégorie proposée.
Le seuil n’est pas universel. Il dépend du coût d’une erreur. Une suggestion interne peut tolérer davantage d’imprécision qu’une action irréversible. Le cahier des charges doit rendre cet arbitrage explicite.
Prévoir un pilote court avant le déploiement
Un pilote de quatre à huit semaines permet de tester le cas d’usage sur un périmètre réduit : une équipe, un type de document ou une boîte fonctionnelle. Le pilote doit avoir une date de fin et une décision prévue : déployer, corriger, réduire le périmètre ou arrêter.
Séquence recommandée :
- valider le processus et les données disponibles ;
- construire un prototype sur des données anonymisées ou maîtrisées ;
- mesurer la qualité sur le jeu de recette ;
- tester avec quelques utilisateurs en conditions réelles ;
- corriger les règles et la gestion des exceptions ;
- décider du déploiement à partir des indicateurs convenus.
Le pilote n’est pas une version gratuite du projet complet. Son budget, ses livrables et les conditions de réutilisation des développements doivent être indiqués dès le départ.
Comparer les prestataires sur une base commune
Envoyez la même version du cahier des charges aux candidats et imposez un format de réponse comparable. Demandez à chacun de distinguer les hypothèses, les éléments inclus, les dépendances, les coûts récurrents et ce qui restera à la charge de votre équipe.
Une grille de sélection simple peut répartir les points ainsi :
| Critère | Pondération indicative |
|---|---|
| Compréhension du besoin métier | 25 % |
| Qualité de la méthode et de la recette | 20 % |
| Sécurité et maîtrise des données | 20 % |
| Intégration et maintenabilité | 15 % |
| Coût total sur douze mois | 15 % |
| Transfert de compétences | 5 % |
Méfiez-vous d’une proposition qui promet un taux de réussite sans avoir vu d’échantillon de données, ou qui ne chiffre pas la maintenance. Demandez une estimation du coût total sur douze mois selon un volume normal et un mois de pointe. Le calcul du retour sur investissement pourra ensuite reprendre les mêmes volumes et le temps réellement économisé, comme dans ce guide de mesure du ROI d’une automatisation IA.
Les erreurs qui fragilisent le projet
Choisir le modèle avant de cadrer le besoin. Le cahier des charges devient alors une justification d’une solution déjà choisie, au lieu d’organiser la décision.
Confondre prototype et système exploitable. Une démonstration peut fonctionner sur dix exemples sans gérer les droits, les erreurs, les pics de charge ni la supervision.
Sous-estimer le nettoyage des données. Les doublons, documents incomplets et champs libres sont souvent la principale source de délai. Un échantillon doit être audité avant de promettre le planning.
Oublier le coût des exceptions. Si 20 % des cas reviennent à l’équipe sans contexte ni explication, l’automatisation peut déplacer la charge au lieu de la réduire.
Ne pas nommer de responsable après la mise en ligne. Les processus, les tarifs et les documents changent. Quelqu’un doit suivre la qualité, mettre à jour les règles et décider quand suspendre le système.
Checklist avant consultation
- Le problème actuel et sa mesure de départ sont documentés.
- Le périmètre et les exclusions sont explicites.
- Un responsable métier et un décideur sont nommés.
- Les sources de données et leurs propriétaires sont connus.
- Des exemples réels anonymisés sont disponibles.
- Les actions autonomes et les validations humaines sont séparées.
- Les contraintes de sécurité et de conservation sont écrites.
- Le jeu de recette et les seuils d’acceptation sont définis.
- Les livrables incluent documentation, formation et procédure de secours.
- Le budget distingue mise en place et exploitation sur douze mois.
FAQ
Faut-il être technique pour rédiger un cahier des charges IA ?
Non. Le responsable métier doit surtout décrire le processus, les données, les erreurs acceptables et le résultat attendu. Un profil technique complète ensuite les intégrations, la sécurité et l’exploitation. Faire rédiger tout le document par un fournisseur avant d’avoir posé le besoin crée un risque de dépendance.
Quelle longueur prévoir ?
Cinq à quinze pages suffisent généralement pour un premier projet de PME, auxquelles s’ajoutent les exemples, le schéma du processus et la grille de recette. La précision des cas concrets compte davantage que le nombre de pages.
Faut-il demander une IA sur mesure ?
Pas par principe. Beaucoup de besoins se traitent avec un modèle existant, des règles métier et une intégration bien conçue. Le sur-mesure se justifie seulement si les données, la performance, la confidentialité ou le volume l’exigent. Le cahier des charges doit laisser les candidats expliquer cette décision.
Qui doit valider le document ?
Au minimum : le responsable métier, la personne chargée du système d’information ou du prestataire informatique, le décideur budgétaire et le référent chargé des données sensibles. Les utilisateurs quotidiens doivent relire le processus cible et les cas limites.
Comment éviter qu’il devienne obsolète ?
Conservez une version courte et datée, puis mettez à jour les annexes de recette, les règles et les volumes après le pilote. Le document doit devenir la référence d’exploitation du système, pas être archivé après la signature.
À retenir
Un bon cahier des charges IA ne cherche pas à impressionner par la technique. Il fixe un problème mesurable, un périmètre, des données autorisées, des contrôles humains et une recette. C’est ce qui permet de comparer des offres, de maîtriser le budget et de décider objectivement si le pilote mérite d’être déployé.
Pour situer ce projet dans une feuille de route plus large, consultez aussi le guide sur les agents IA pour PME et l’analyse du coût réel d’une automatisation back-office.
Je suis Joseph Nahed, associé opérationnel. J’entre au capital de TPE et PME de 300 k€ à 5 M€ de chiffre d’affaires contre mon expertise de pilotage et mes outils, plutôt que de facturer une mission de conseil. Si vous voulez transformer ce cahier des charges en projet mesurable, découvrez le modèle.