Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 2 octobre 2026.

En bref

Rédiger un cahier des charges avec l’IA générative consiste à faire produire un brouillon structuré depuis le besoin et les documents existants, puis à vérifier chaque exigence avant publication. Pour un acheteur public, l’article L2111-1 du Code de la commande publique (version en vigueur depuis le 16 octobre 2025) impose que la nature et l’étendue des besoins soient « déterminées avec précision avant le lancement de la consultation ».

Selon le rapport The Root Causes of Failure for Artificial Intelligence Projects de la RAND Corporation (13 août 2024), plus de 80 % des projets d’IA échouent, d’abord par mauvaise compréhension du problème à résoudre.

La CNIL rappelle (18 juillet 2024) que ces systèmes produisent des résultats inexacts qui peuvent « paraître plausibles » et que la responsabilité reste celle de l’organisme utilisateur. La seconde partie détaille ce qu’un cahier des charges IA doit contenir quand l’objet du marché est un système d’IA générative.

1. Pourquoi le cahier des charges décide-t-il du sort d’un projet d’IA ?

Parce que les causes d’échec documentées se jouent avant la première ligne de code. Le rapport de la RAND Corporation cité plus haut, fondé sur 65 entretiens avec des data scientists expérimentés, relève un taux d’échec deux fois supérieur à celui des projets informatiques sans IA et désigne la définition du problème comme première cause.

Le Code de la commande publique encadre ce travail : l’article L2111-1 impose la précision du besoin avant la consultation, et l’article R2111-1 autorise l’acheteur à « solliciter des avis ou informer les opérateurs économiques de son projet et de ses exigences ». La fiche pratique pour l’achat responsable de solutions d’IA de la DINUM, de la Direction des achats de l’État et de l’Écolab du CGDD (novembre 2025) ajoute que ce sourçage permet « de mieux définir le besoin ».

Le cahier des clauses techniques particulières (CCTP) désigne, selon la même fiche, « un document contractuel regroupant les clauses techniques détaillant les travaux ou prestations à réaliser ». C’est lui que l’IA générative peut aider à produire.

2. Comment utiliser l’IA générative pour rédiger un cahier des charges ?

En lui fournissant des sources vérifiées, en lui demandant des exigences numérotées plutôt qu’un texte final, et en relisant chaque exigence contre ces sources.

2.1 Quelles sources d’entrée donner au modèle ?

Celles que l’acheteur transmettrait à un prestataire : le besoin exprimé par les futurs utilisateurs, les marchés précédents et les référentiels applicables. Le CCAG-TIC (arrêté du 30 mars 2021) fixe déjà les clauses générales de confidentialité, de vérification, de réversibilité et de propriété intellectuelle ; le CCTP les complète.

La confidentialité s’applique dès cette étape : la CNIL écrit que les utilisateurs « ne devraient soumettre que des informations qu’ils sont autorisés à partager », et l’ANSSI, dans ses Recommandations de sécurité pour un système d’IA générative (ANSSI-PA-102, 29 avril 2024), proscrit les outils d’IA générative sur Internet « pour un usage professionnel impliquant des données sensibles » (R34).

2.2 Comment faire produire et structurer les exigences ?

En demandant au modèle des exigences numérotées, formulées en résultat attendu, puis en reprenant la main sur la rédaction. L’article R2111-8 permet de formuler les spécifications par référence à des normes, en termes de performances ou d’exigences fonctionnelles, ou en combinant les deux ; l’expression fonctionnelle décrit un service rendu sans présumer de la solution.

L’article R2111-7 interdit de mentionner une marque ou un procédé lorsque cette mention peut favoriser ou éliminer certains opérateurs ; un brouillon nourri de la documentation d’un éditeur en reprend le vocabulaire. Chaque exigence porte une formulation vérifiable, un niveau et une origine ; sans origine, elle a pu être inventée.

2.3 Comment relire les exigences avant publication ?

En vérifiant que chaque exigence remonte à une source réelle, que les exigences ne se contredisent pas et que rien d’essentiel ne manque. Le guide d’usage de l’IA pour les agents publics de l’État de la DINUM (édition 2026) demande de toujours vérifier les résultats de l’outil, d’autant plus rigoureusement que l’activité est sensible, et note que l’IA « peut citer des textes de loi qui n’existent pas » : chaque texte cité est ouvert avant d’être conservé.

La relecture de cohérence confronte le CCTP au CCAP et au règlement de la consultation ; celle d’exhaustivité se fait contre la liste de la section 5. TW3 Partners a construit pour l’acheteur d’un grand groupe de l’énergie un module qui extrait les exigences d’un cahier des charges, en contrôle la clarté et détecte les contradictions avant publication (cas publié).

3. Quelles sont les limites de l’IA générative pour un acheteur ?

Trois limites tiennent à la technique et au droit, et aucune ne se corrige en changeant d’outil.

Les exigences inventées. Un article cité de travers, une norme qui n’existe pas, un seuil sorti de nulle part : la CNIL constate que les résultats inexacts peuvent « paraître plausibles ».

Les exigences non vérifiées. Un brouillon généré est long, bien formé et uniforme, ce qui relâche l’attention du relecteur.

La responsabilité. La CNIL rappelle que « c’est l’organisme utilisateur qui engagera sa responsabilité légale en cas de mauvaise utilisation de l’IA par son personnel ». Le guide de la DINUM, qui répond à une enquête menée fin 2025 auprès de 2 000 agents publics, pose le même principe et demande de signaler l’usage de l’IA lorsqu’elle joue un rôle substantiel. Une spécification irrégulière reste celle de l’acheteur qui la publie.

4. Que doit contenir le cahier des charges d’un projet d’IA générative ?

Les rubriques d’un marché numérique classique, plus quatre séries d’exigences propres à l’IA.

4.1 Quelles exigences sur les données et l’hébergement ?

Le CCTP précise quelles données le système traite, où elles sont hébergées et ce que le titulaire peut en faire. Si des données personnelles sont traitées pour le compte de l’acheteur, l’article 28 du RGPD impose un contrat qui définit l’objet, la durée, la nature et la finalité du traitement, et l’article 35 une analyse d’impact avant tout traitement susceptible d’engendrer un risque élevé.

L’ANSSI recommande d’héberger le système « dans des environnements de confiance cohérents avec les besoins de sécurité » (R11) et, en cloud public, de « privilégier un hébergement SecNumCloud » lorsque les données sont sensibles ou l’impact métier critique (R14).

4.2 Quelles exigences sur le modèle, la sécurité et la supervision ?

Le CCTP nomme le niveau de qualité attendu et les actions que le système n’a pas le droit de déclencher seul. La fiche DINUM/DAE propose d’exiger « l’engagement à ne pas augmenter la complexité de l’algorithme sans en informer le pouvoir adjudicateur ». Le guide de l’ANSSI, qui compte 35 recommandations, en fournit quatre à reprendre telles quelles : proscrire l’usage automatisé du système pour des actions critiques sur le SI (R9), filtrer les entrées et les sorties (R25), journaliser l’ensemble des traitements (R29), prévoir un mode dégradé sans IA (R15).

L’article 26 du règlement (UE) 2024/1689 impose, pour un système à haut risque, un contrôle humain confié à des personnes disposant « des compétences, de la formation et de l’autorité nécessaires » et des journaux conservés « d’au moins six mois ».

4.3 Quelles clauses de réversibilité, de propriété et de recette ?

Le CCAG-TIC les prévoit, et le CCTP les rend concrètes. Son article 38 définit la réversibilité comme le retour de responsabilité à l’acheteur et la transférabilité comme le transfert à un nouveau prestataire, avec un plan de réversibilité et une période de transition de six mois au plus ; son article 42 impose au titulaire sortant « un accès aux matériels et aux logiciels » pendant le transfert. L’article R2111-5 permet de préciser « si le transfert des droits de propriété intellectuelle sera exigé ».

Les critères d’acceptation reprennent deux recommandations de l’ANSSI avant déploiement en production : des audits de sécurité (R23) et des tests fonctionnels métier portant sur la performance et la qualité des réponses (R24), traduits en un jeu de cas validé par les métiers, un seuil de réponses correctes et le comportement attendu hors périmètre.

4.4 Quelles obligations au titre de l’AI Act ?

Le règlement (UE) 2024/1689 (Journal officiel du 12 juillet 2024) impose d’abord de classer le système : son annexe III liste les domaines à haut risque, dont l’éducation, l’emploi et l’accès aux prestations publiques essentielles. Selon le calendrier publié par la Commission européenne (page mise à jour le 3 août 2026), les obligations propres à ces systèmes s’appliquent à partir du 2 décembre 2027 ; les règles de transparence de l’article 50 s’appliquent depuis août 2026 et l’obligation de maîtrise de l’IA de l’article 4 depuis le 2 février 2025.

Les sanctions de l’article 99 atteignent 35 millions d’euros ou 7 % du chiffre d’affaires annuel mondial pour les pratiques interdites, 15 millions d’euros ou 3 % pour les manquements des déployeurs. Pour l’acheteur : classification justifiée dans le dossier, information des utilisateurs, formation des agents et, à haut risque, clauses contractuelles types de la Commission européenne (version du 5 mars 2025).

5. Modèle de plan d’un cahier des charges IA

RubriqueCe que l’acheteur y écritRéférence
Contexte et besoinProcessus visé, utilisateurs, volumes, résultat attendu, sourçageCCP, art. L2111-1 et R2111-1
Exigences fonctionnellesExigences numérotées, formulées en résultat, avec niveau, sans marqueCCP, art. R2111-7 et R2111-8
Données et hébergementSources, données personnelles, rétention, droits d’accès, analyse d’impact, localisation et qualification de l’hébergementRGPD, art. 28 et 35 ; ANSSI, R11 et R14
Modèle et qualitéPrécision attendue, information sur les évolutions du modèleFiche DINUM/DAE
Sécurité et supervisionActions interdites, filtrage, journalisation, mode dégradé, contrôle humainANSSI, R9, R15, R25, R29 ; AI Act, art. 26
Recette et acceptationJeu de cas métier, seuils, audit de sécurité avant productionANSSI, R23 et R24 ; CCAG-TIC, art. 29 à 36
Réversibilité et propriétéPlan de réversibilité, éléments restitués, droits sur les résultatsCCAG-TIC, art. 38 et 42 ; CCP, art. R2111-5
ConformitéClassification AI Act, transparence, formation, clauses typesAI Act, art. 4, 26, 50 et annexe III

Ce plan ne remplace pas la relecture. Il sert de liste de contrôle pour vérifier qu’un cahier des charges IA, rédigé avec ou sans assistance, couvre ce que les textes et les référentiels attendent.

6. FAQ

Peut-on confier la rédaction complète d’un cahier des charges à une IA générative ?
Non. L’outil produit un brouillon à partir des sources fournies, et chaque exigence est ensuite vérifiée contre sa source. La CNIL rappelle que l’organisme utilisateur engage sa responsabilité.

Quelles informations peut-on saisir dans un assistant grand public pour préparer un marché ?
Seulement celles que l’on est autorisé à partager, selon la CNIL. L’ANSSI proscrit les données sensibles dans les outils d’IA générative exposés sur Internet (R34), ce qui couvre les pièces d’une consultation non publiée.

Un assistant documentaire interne est-il un système à haut risque au sens de l’AI Act ?
La classification dépend de la finalité. L’annexe III vise des domaines précis (biométrie, infrastructures critiques, éducation, emploi, services essentiels, entre autres) et ne mentionne pas la recherche documentaire interne en tant que telle.

Faut-il exiger un hébergement qualifié SecNumCloud ?
L’ANSSI le recommande en cloud public lorsque les données sont sensibles ou l’impact métier critique (R14). Sinon, le CCTP exige un hébergement cohérent avec les besoins de sécurité (R11).

Que doit prévoir la clause de réversibilité d’un marché d’IA ?
Le plan de réversibilité du CCAG-TIC (article 38) et la liste des éléments restitués : corpus indexé, jeu de test, instructions du modèle, journaux, poids d’un modèle ajusté le cas échéant. L’article 42 impose l’accès aux matériels et logiciels pendant la transition.

7. Pour aller plus loin

8. Sources