Cahier des charges consultant IA : cadrer une mission utile

Un cahier des charges pour un consultant IA ne doit pas commencer par « nous voulons un chatbot » ou « automatisez notre entreprise ». Il doit décrire une situation de travail, une décision à améliorer, les données autorisées, les erreurs inacceptables et la preuve attendue à la fin de la mission.

La technologie vient après. Sinon, les prestataires ne chiffrent pas le même objet : l’un vend un atelier, l’autre un prototype, un troisième une intégration complète. Les prix deviennent incomparables et le projet paraît flou alors que le document de départ mélange simplement plusieurs missions.

Le modèle proposé ici comporte treize blocs. Il convient à une PME, une direction métier ou une équipe projet qui prépare une consultation. Il ne remplace ni l’analyse juridique, ni la sécurité, ni les règles d’achat propres à l’organisation.

Réponse en bref

Un bon cahier des charges de conseil IA doit permettre à plusieurs prestataires de répondre au même problème et d’être évalués sur des preuves comparables.

Les treize blocs sont :

1. contexte et propriétaire ;
2. problème de travail ;
3. résultat attendu ;
4. utilisateurs et personnes concernées ;
5. périmètre et exclusions ;
6. données et systèmes ;
7. niveau d’autonomie ;
8. risques et contrôles ;
9. protocole de test ;
10. livrables ;
11. transfert de compétences ;
12. exploitation et sortie ;
13. critères d’acceptation.

Le document doit distinguer quatre prestations possibles : cadrer, construire, former et exploiter. Une même personne peut en assurer plusieurs, mais le devis doit montrer où chacune commence et se termine.

Pourquoi les consultations IA deviennent vite incomparables

Le mot « IA » peut désigner un assistant conversationnel, un moteur de recherche documentaire, une automatisation avec une étape générative, un agent qui choisit des outils ou une simple formation à un service existant.

Deux propositions peuvent donc porter le même titre tout en couvrant des réalités différentes.

Formulation floue	Questions encore ouvertes
créer un assistant interne	pour quelle tâche, avec quelles sources, pour quels utilisateurs ?
automatiser le support	préparer un brouillon ou envoyer directement une réponse ?
connecter l’IA au CRM	lire, proposer une modification ou écrire dans la base ?
former les équipes	à quel rôle, sur quels cas et avec quelle évaluation ?
améliorer la productivité	quelle unité de travail, quelle référence et quelle période ?

Les clauses contractuelles européennes pour l’achat public d’IA ne sont pas un modèle universel pour une PME. Elles fournissent néanmoins un signal utile : un achat responsable doit clarifier responsabilités, documentation, données, contrôle, suivi et évolution du système. La version publiée en mars 2025 distingue d’ailleurs un modèle complet pour les usages à haut risque et une version légère personnalisable.

Ce principe s’applique aussi à une mission plus modeste : proportionner le document au risque, sans supprimer les questions qui déterminent la réussite.

Bloc 1 : contexte et propriétaire

Commencez par nommer l’équipe qui porte le projet et la personne capable d’arbitrer.

Décrivez en cinq lignes :

• l’activité concernée ;
• le rôle du commanditaire ;
• l’équipe utilisatrice ;
• le système ou la méthode actuelle ;
• l’événement qui déclenche la consultation.

Évitez la longue présentation institutionnelle. Le consultant a surtout besoin de comprendre qui décide, qui utilise, qui administre et qui peut arrêter.

Formulation à reprendre :

Le projet est porté par [fonction]. Il concerne [équipe ou processus]. La décision finale appartient à [fonction]. Les validations données, sécurité et juridique relèvent de [fonctions]. Le pilote peut être interrompu par [fonction].

Un propriétaire sans temps disponible est un risque de projet. Indiquez la disponibilité réelle pour les ateliers, les tests et les arbitrages.

Bloc 2 : problème de travail

Décrivez le travail avant de décrire la solution.

Une fiche utile répond à six questions :

Élément	Question
déclencheur	qu’est-ce qui lance la tâche ?
entrées	quels documents ou champs sont nécessaires ?
transformation	que fait aujourd’hui la personne ?
sortie	quel livrable ou quelle décision est produit ?
exception	qu’est-ce qui fait sortir du chemin normal ?
conséquence	que se passe-t-il si le résultat est faux ?

La phrase « la tâche prend trop de temps » ne suffit pas. Il faut savoir si ce temps vient d’une recherche, d’une saisie répétée, d’une comparaison, d’un arbitrage ou d’une attente entre deux équipes.

Une étape déterministe mérite souvent une règle classique. Une étape qui demande de reformuler, classer ou rapprocher des formulations peut justifier une IA. Le cahier des charges doit autoriser le consultant à conclure que l’IA n’est pas nécessaire sur une partie du processus.

Bloc 3 : résultat attendu

Remplacez les ambitions générales par un changement observable.

Un résultat attendu peut être :

• réduire les oublis dans un dossier ;
• produire un brouillon structuré à relire ;
• retrouver les passages qui soutiennent une réponse ;
• classer des demandes dans une nomenclature définie ;
• signaler une donnée manquante avant traitement ;
• rendre une procédure transmissible à une autre personne.

N’écrivez pas « zéro erreur » sans définir le périmètre. N’annoncez pas non plus un gain de temps avant d’avoir mesuré la référence.

Formulation à reprendre :

À la fin du pilote, [rôle] doit pouvoir produire [sortie] à partir de [entrées], sur [périmètre], avec [contrôles]. La comparaison portera sur [nombre ou période] par rapport à [méthode actuelle]. Les erreurs critiques sont [liste].

Cette phrase devient le contrat de mesure du projet.

Bloc 4 : utilisateurs et personnes concernées

Un outil utilisé par trois analystes n’a pas le même besoin qu’un service ouvert à toute l’entreprise. Décrivez :

• les rôles utilisateurs ;
• leur niveau technique ;
• la fréquence d’usage ;
• les langues nécessaires ;
• les besoins d’accessibilité ;
• les personnes dont les données ou décisions peuvent être affectées.

Le règlement européen sur l’IA demande, dans son cadre applicable, de tenir compte des connaissances, de l’expérience, de la formation et du contexte d’utilisation lorsqu’il traite de maîtrise de l’IA. Le cahier des charges ne doit pas transformer ce point en formule juridique générique. Il doit en tirer une exigence pratique : adapter la formation et les contrôles aux personnes qui utiliseront réellement le système.

Si une sortie contribue à une décision sur une personne, indiquez-le explicitement. Le consultant pourra alors proposer un périmètre, une supervision et des spécialistes adaptés.

Bloc 5 : périmètre et exclusions

Le périmètre liste ce qui sera réellement traité. Les exclusions évitent qu’une démonstration devienne silencieusement un produit en exploitation.

Précisez :

• le processus inclus ;
• les unités ou équipes incluses ;
• les formats d’entrée ;
• les langues ;
• les systèmes à consulter ;
• les systèmes autorisés en écriture ;
• le volume de test ;
• la durée du pilote.

Ajoutez ensuite une liste d’exclusions nette.

Exemple :

Le pilote prépare un brouillon à partir de documents synthétiques ou autorisés. Il n’envoie aucun message, ne modifie aucun dossier métier, ne traite pas de données sensibles et ne prend aucune décision sur une personne.

Une exclusion n’est pas une faiblesse. Elle rend la première étape testable.

Bloc 6 : données et systèmes

Inventoriez les catégories, pas les secrets. Le cahier des charges envoyé à plusieurs prestataires ne doit contenir ni export privé, ni identifiant, ni clé, ni document client.

Pour chaque source prévue, notez :

Champ	Exemple de réponse
propriétaire	direction des opérations
catégorie	procédure interne validée
sensibilité	interne, sans donnée personnelle dans le pilote
format	PDF texte et tableur
volume	plage approximative
fréquence de mise à jour	mensuelle
accès envisagé	copie synthétique puis connecteur en lecture seule
durée de conservation	à définir avec le responsable compétent

La CNIL recommande de déterminer les finalités, de limiter les données et d’encadrer les usages. Ses questions-réponses sur l’IA générative rappellent aussi l’importance des paramètres du service, de la réutilisation éventuelle des données et des règles internes.

Demandez au prestataire d’indiquer clairement les flux : origine, transformation, fournisseur, stockage, journalisation, suppression et sous-traitants nécessaires.

Bloc 7 : niveau d’autonomie

Ne demandez pas un « agent autonome » comme caractéristique de prestige. Décrivez les actions autorisées.

Niveau	Capacité	Exemple
0	répondre sans outil	expliquer une procédure publique
1	lire des sources autorisées	rechercher dans un corpus interne
2	préparer une proposition	produire un brouillon ou une fiche
3	demander une approbation	présenter une action et ses paramètres
4	exécuter une action bornée	écrire après validation dans une destination précise

Pour chaque action, précisez :

• l’identité utilisée ;
• les permissions ;
• les paramètres visibles au valideur ;
• la personne qui approuve ;
• la possibilité d’annuler ;
• le journal attendu ;
• le critère d’arrêt.

Le protocole human in the loop détaille la différence entre une approbation décorative et une vraie décision.

Bloc 8 : risques et contrôles

Le NIST AI RMF est un cadre volontaire. Il organise la gestion des risques autour d’actions de gouvernance, cartographie, mesure et traitement. Un cahier des charges court peut reprendre cette logique sans prétendre réaliser une conformité complète.

Construisez une matrice simple :

Risque	Situation	Contrôle avant effet	Preuve
fait inventé	source absente	abstention et référence obligatoire	test sans source
donnée interdite	document sensible	filtre d’entrée et politique d’accès	cas de refus
mauvaise destination	action externe	liste fermée et approbation	journal de décision
instruction hostile	contenu récupéré	séparation données-instructions	test adversarial
dépendance indisponible	API en erreur	timeout et reprise	scénario d’échec
dérive de coût	boucle trop longue	budget et nombre d’étapes	arrêt automatique

L’ANSSI recommande une approche de sécurité qui couvre l’architecture et le cycle de vie du système d’IA générative. Pour une mission réelle, le RSSI, le DPO, le juridique et les responsables métier restent propriétaires de leurs décisions.

Bloc 9 : protocole de test

Un projet ne se valide pas avec trois démonstrations choisies par le prestataire.

Demandez :

1. un jeu de cas représentatifs ;
2. des cas incomplets ;
3. des cas ambigus ;
4. des cas sensibles ou interdits ;
5. des erreurs de dépendance ;
6. des tentatives de sortie de périmètre ;
7. une règle de notation ;
8. des seuils de blocage.

Séparez qualité, sécurité et exploitation. Une moyenne élevée ne doit pas masquer une action interdite.

Le protocole d’évaluation d’un assistant IA sur 50 cas propose une base pour construire ce jeu. Le nombre doit être adapté au risque et à la diversité du processus.

Bloc 10 : livrables

Un livrable doit pouvoir être relu sans le prestataire.

Selon la mission, demandez :

• carte du processus actuel ;
• décision d’architecture argumentée ;
• inventaire des données et flux ;
• prototype borné ;
• configuration et code versionnés ;
• registre des risques ;
• jeu de tests et résultats ;
• procédure de lancement et d’arrêt ;
• documentation utilisateur ;
• documentation d’administration ;
• plan de transfert ;
• estimation d’exploitation.

Évitez « rapport final » sans sommaire attendu. Demandez le format, le propriétaire, le niveau de détail et les conditions de réutilisation.

Bloc 11 : transfert de compétences

Une mission réussie ne crée pas une dépendance invisible.

Précisez qui doit savoir :

• utiliser le système ;
• vérifier une sortie ;
• modifier une règle ;
• ajouter un cas de test ;
• lire un incident ;
• mettre à jour une source ;
• révoquer un accès ;
• décider d’une nouvelle version.

Le transfert peut comprendre des ateliers, une séance d’administration, des exercices et une passation. Il doit posséder son propre critère de réussite. Le dossier de réversibilité d’une mission IA propose huit pièces à recevoir et un exercice de reprise à blanc après la réalisation.

Exemple :

Deux personnes internes doivent pouvoir relancer le jeu de tests, retrouver la configuration active et désactiver un outil sans intervention du prestataire.

Si le besoin principal est l’adoption collective, une formation IA en entreprise peut être plus pertinente qu’un développement.

Bloc 12 : exploitation et sortie

Un prototype a une date de fin. Un service a un propriétaire, un coût et une procédure de maintenance.

Demandez au consultant de chiffrer séparément :

• cadrage ;
• construction ;
• licences et consommation ;
• hébergement ;
• surveillance ;
• mises à jour ;
• support ;
• réversibilité.

Définissez aussi la sortie :

• export des données ;
• remise du code et de la documentation prévus ;
• suppression des accès ;
• suppression ou restitution des copies ;
• état des dépendances ;
• dernier jeu de tests ;
• responsabilités après la mission.

Un faible prix de construction peut masquer un coût d’exploitation important. Comparez le coût sur une période explicite, pas seulement le devis initial.

Bloc 13 : critères d’acceptation

Le critère d’acceptation relie un livrable à une preuve.

Livrable	Critère	Méthode	Décision
carte du processus	étapes, rôles et exceptions couverts	revue métier	accepter ou corriger
prototype	aucune action hors périmètre	jeu de tests	poursuivre ou bloquer
documentation	reprise possible par une autre personne	exercice de passation	accepter ou compléter
sécurité	permissions et journaux conformes au périmètre	revue compétente	autoriser ou arrêter
qualité	seuils définis par type d’erreur	évaluation sur cas gelés	déployer, limiter ou refuser

Une réception « au ressenti » déplace les désaccords à la fin. La matrice les rend visibles avant le devis.

Le modèle prêt à envoyer

Vous pouvez reprendre cette structure :

1. Contexte et responsable
Organisation :
Équipe concernée :
Décideur :
Personnes de validation :

2. Problème de travail
Déclencheur :
Entrées :
Étapes actuelles :
Sortie :
Exceptions :
Conséquence d’une erreur :

3. Résultat attendu
Capacité visée :
Référence actuelle :
Période ou échantillon :
Erreurs critiques :

4. Utilisateurs et personnes concernées
Rôles :
Niveaux :
Fréquence :
Personnes affectées :

5. Périmètre et exclusions
Inclus :
Exclu :

6. Données et systèmes
Sources :
Sensibilité :
Accès :
Conservation :

7. Autonomie
Actions de lecture :
Actions de proposition :
Actions soumises à approbation :
Actions interdites :

8. Risques et contrôles
Risques principaux :
Contrôles attendus :
Responsables :

9. Tests
Cas nominaux :
Cas d’erreur :
Cas adversariaux :
Seuils :

10. Livrables
Formats :
Propriétaires :

11. Transfert
Personnes à rendre autonomes :
Exercice de validation :

12. Exploitation et sortie
Maintenance :
Coûts :
Réversibilité :

13. Acceptation
Preuves attendues :
Décisions possibles :

Ce texte est un point de départ, pas une clause contractuelle.

Comparer les réponses sans faux score

Une grille sur 100 donne une impression de précision. Je préfère une échelle courte accompagnée de critères éliminatoires.

Notez chaque axe de 0 à 3 :

• 0 : absent ;
• 1 : déclaration générale ;
• 2 : réponse concrète mais incomplète ;
• 3 : réponse vérifiable, adaptée au contexte.

Évaluez :

1. compréhension du processus ;
2. proportionnalité de la solution ;
3. maîtrise des données ;
4. architecture et permissions ;
5. protocole de test ;
6. gestion des erreurs ;
7. transfert ;
8. exploitation et sortie.

Ajoutez des critères éliminatoires : promesse de résultat impossible, refus de documenter les flux, permissions excessives, absence de test, données utilisées sans cadre ou dépendance non déclarée.

Le score aide à lire. Il ne remplace pas les références, l’entretien technique, la revue contractuelle ni l’adéquation humaine.

Limites

Ce modèle décrit un cadrage de mission. Il ne constitue ni un conseil juridique, ni un dossier d’achat public, ni une analyse de conformité au règlement européen sur l’IA ou au RGPD. Les obligations dépendent du rôle de l’organisation, du système, du contexte, des personnes affectées et du calendrier réglementaire applicable.

Les clauses européennes citées visent l’achat public d’IA et doivent être personnalisées. Le NIST AI RMF est volontaire. Les recommandations CNIL et ANSSI doivent être appliquées par les personnes compétentes au contexte réel.

Un cahier des charges précis ne garantit pas la réussite. Il rend comparables les propositions, expose les décisions manquantes et permet d’arrêter plus tôt une solution mal proportionnée.

À propos de l’auteur

Je suis Ayoub Kahouadji, formateur et consultant IA. J’aide les équipes à transformer un besoin flou en cas testable, puis à choisir entre accompagnement, formation, workflow et réalisation technique sans promettre un résultat que le projet ne peut pas prouver.

Prochaine étape

Remplissez d’abord les blocs 2, 3, 5 et 13. S’ils restent vagues, il est trop tôt pour comparer des outils ou demander un prix ferme. Pour cadrer la mission avec un interlocuteur, consultez la page conseil IA.