Acheter l’IA concrètement en structurant son premier appel d’offres
Ce document propose un cadre de structuration et des repères opérationnels pour les démarches achats en matière d’intelligence artificielle. Il ne constitue pas une méthode unique ni un référentiel normatif, et doit être adapté par chaque organisation en fonction de son contexte, de ses enjeux et de ses contraintes.
Focus : clauses juridiques, auditabilité algorithmique, sécurisation des données internes, modèle économique.
Executive summary
Acheter une solution IA “concrètement” revient à contractualiser trois choses : (1) les données (usage, cloisonnement, transferts), (2) l’auditabilité (logs, traçabilité, rejouabilité), (3) la gouvernance (changements de modèle, incidents, réversibilité) (4) le modèle économique (unités facturables, scénarios pilote/nominal/pic, plafonds, alertes, révisions tarifaires).
L’AI Act pousse vers plus de documentation, de journalisation, de transparence et de robustesse/cybersécurité, avec une application progressive (jalons 2025, application générale 2026). [1]
Côté RGPD, un modèle entraîné sur des données personnelles n’est pas automatiquement “anonyme” : l’évaluation est au cas par cas et doit être documentée. [2]
Cet article sous forme de guide fournit une trame RFP, un socle de clauses contractuelles structurantes, une checklist, une scorecard et un cadre pour rendre le modèle économique gouvernable dès l’appel d’offres.
Exigences réglementaires et risques critiques à intégrer dès le RFP
Dans l’AI Act, quatre exigences structurantes méritent d’être “importées” dans vos RFP, même si votre cas d’usage Achats IT/GENEX n’est pas classé « haut risque » : documentation, journalisation, transparence d’usage, robustesse/cybersécurité. [3]
Si votre solution repose sur un modèle d’IA à usage général, exigez en plus les éléments attendus côté fournisseur de modèle : documentation, informations pour intégrateurs, politique droits d’auteur, résumé du contenu d’entraînement. [4]
Risques à adresser dès l’appel d’offres :
- Fuite de données internes (prompts, logs, plugins, connecteurs) et impossibilité d’audit si les journaux/versions ne sont pas maîtrisés.
- Erreur “documentaire” (GENEX) : versions contradictoires → hallucinations → décision non défendable si les sorties ne sont pas sourcées.
- Cyber : filtrage entrées/sorties, mode dégradé sans IA, exigences d’intégrité, hébergement de confiance si données sensibles (ANSSI). [5]
- Menace : l’IA générative est levier d’attaque et cible (CERT-FR). [6]
Côté RGPD : un modèle entraîné sur des données personnelles ne peut pas, dans tous les cas, être considéré comme anonyme ; il faut une démonstration documentée (résistance à l’extraction et aux requêtes). [2]
Structurer un RFP IA
Un RFP IA ne peut pas être un RFP logiciel classique enrichi de quelques critères techniques.
Il doit articuler décision, preuve et gouvernance dès le cadrage initial.
L’enjeu n’est pas seulement de comparer des solutions, mais de structurer un processus permettant :
- d’aligner les parties prenantes,
- d’objectiver les exigences,
- d’exiger des preuves vérifiables,
- et de sécuriser la décision avant contractualisation.
Le tableau ci-dessous présente un parcours structuré en 10 étapes, depuis le cadrage jusqu’au pilotage en run.
Il permet de transformer une intention (« intégrer de l’IA ») en décision gouvernable.
Guide pas‑à‑pas
Un premier appel d’offres IA ne se structure pas autour d’un outil, mais autour d’un cadre.
Avant de comparer des solutions, il faut clarifier ce que l’on cherche à décider, ce que l’on accepte comme niveau de preuve et comment l’organisation pilotera le risque.
Ce guide pas-à-pas propose une structuration en cinq blocs : objectifs, périmètre, exigences techniques, exigences juridiques et critères opérationnels.
Il permet de transformer une intention technologique en dispositif gouvernable.
L’IA devient maîtrisée lorsque ces fondations sont posées en amont et non après la signature.
Checklist RFP
Un RFP IA ne doit rien laisser à l’implicite.
Cette checklist permet de vérifier que chaque dimension structurante a été formalisée : cas d’usage, données, traçabilité, sécurité, cadre juridique, modèle économique et réversibilité.
Elle sert à deux choses :
sécuriser la comparaison des offres et éviter qu’un point critique ne soit découvert après contractualisation.
Si un élément n’est pas documenté, prouvé ou objectivable, il ne doit pas être considéré comme acquis.
Scorecard d’évaluation fournisseurs
Comparer des fournisseurs IA ne consiste pas à additionner des fonctionnalités.
Une scorecard structurée permet d’objectiver la décision en pondérant ce qui compte réellement : valeur métier, traçabilité, sécurité, conformité, modèle économique et capacité à opérer dans la durée.
L’objectif n’est pas de désigner “la meilleure démo”, mais la solution la plus défendable au regard des risques, des preuves et des engagements contractuels.
Sans grille multicritère explicite, la décision reste intuitive.
Avec une scorecard, elle devient arbitrable et documentable.
Audit & tests d’acceptation
Un projet IA ne se valide pas sur une promesse, mais sur des tests.
L’audit et les tests d’acceptation ont un objectif simple : vérifier que la solution est robuste, traçable, conforme et exploitable en conditions réelles.
Il ne s’agit pas de tester “si ça marche”, mais de tester :
- si la décision est défendable,
- si la sécurité tient face aux usages réels,
- et si l’organisation peut opérer sans dépendance aveugle.
Un Go/NoGo IA sérieux repose toujours sur des preuves testées, pas sur une démonstration convaincante.
Modèle économique
L’IA ne se facture pas comme une licence classique.
Le véritable enjeu n’est pas le prix affiché, mais le modèle économique qui fera évoluer le coût avec l’usage, la montée en charge, la volumétrie ou les fonctionnalités activées.
Ill faut donc rendre le coût gouvernable dès l’appel d’offres
Une solution peut être techniquement conforme et juridiquement sécurisée, tout en devenant économiquement incontrôlable si le modèle n’est pas cadré dès le RFP.
Structurer un premier appel d’offres IA suppose donc d’objectiver :
- les unités de facturation
- les variables d’indexation
- les mécanismes de plafonnement
- les leviers de pilotage et d’alerte
- les conditions d’évolution tarifaire
Sans cela, on signe une architecture fonctionnelle… mais une exposition financière ouverte.
Identifier tous les postes de coûts
Le prix d’une solution IA ne se limite pas aux tokens.
Il faut cartographier :
- consommation du modèle (API, tokens, batch, contexte long)
- RAG et stockage vectoriel
- infrastructure (GPU, régions, capacité réservée)
- exploitation (monitoring, SLA premium)
- sécurité & conformité
- évolutions (fine-tuning, montée en charge)
- réversibilité et sortie
Sans cette cartographie, la dérive budgétaire est quasi inévitable.
Formaliser des exigences économiques claires
Un RFP IA structuré doit imposer :
- une définition précise des unités facturables
- trois scénarios standardisés : pilote / nominal / pic
- des exemples de factures détaillées
- des exports d’usage par projet
- des mécanismes d’alerte
- des plafonds contractuels
- des conditions de révision encadrées
- un coût de réversibilité explicite
L’objectif n’est pas d’obtenir le prix le plus bas mais d’obtenir un modèle lisible et pilotable.
Comparer les offres sur des scénarios réels
Comparer uniquement un tarif unitaire est trompeur.
La comparaison doit se faire sur :
- un scénario pilote (validation)
- un scénario nominal (usage courant)
- un scénario pic (charge maximale)
C’est là que les écarts apparaissent.
En synthèse
Un modèle économique IA doit être :
- prévisible
- plafonné
- transparent
- pilotable
- et réversible
Un RFP mal structuré ne crée pas un risque immédiat, il crée un risque différé.
C’est au moment de l’appel d’offres que l’IA devient maîtrisable.
Clauses contractuelles
Un contrat IA ne peut pas être un contrat logiciel standard.
Certaines clauses deviennent structurantes dès le premier déploiement : auditabilité, traçabilité des données, sous-traitance, transferts, réversibilité, journalisation.
L’objectif n’est pas seulement de “se couvrir” juridiquement, mais de rendre l’outil gouvernable dans le temps.
Un contrat bien structuré anticipe les tensions futures : évolution du modèle, changement d’hébergement, incident de sécurité, dépendance technique.
Ce qui n’est pas cadré au moment de la signature devient difficile à négocier une fois l’usage installé.
NB : Les éléments ci-dessous constituent des indications de contenu contractuel et des points d’attention structurants. Ils n’ont pas vocation à être repris tels quels, mais à être traduits et formalisés dans un cadre rédactionnel juridique adapté, en fonction du contexte et du niveau de criticité du projet.
Modèles de clauses principales à insérer
Un RFP bien structuré doit se traduire en clauses contractuelles précises.
Les modèles ci-dessous couvrent les points les plus sensibles d’un projet IA : auditabilité, traçabilité, données, sous-traitance, transferts, responsabilité et réversibilité.
Ils constituent une base opérationnelle destinée à sécuriser la décision et à rendre l’outil gouvernable dans le temps.
Chaque clause doit naturellement être adaptée au niveau de criticité du projet, mais ces formulations permettent d’éviter les angles morts au moment de la signature.
Les 6 clauses clés prêtes à intégrer
Structurer un RFP ne suffit pas si les exigences ne se traduisent pas en clauses concrètes.
Les clauses clés présentées ci-dessous ne sont pas des “options juridiques”, mais des leviers de gouvernance : auditabilité, usage des données, sous-traitance, transferts, réversibilité.
Elles ont vocation à être intégrées en étant adaptées au contexte de criticité de votre organisation.
L’objectif n’est pas d’alourdir le contrat, mais d’éviter les zones grises qui apparaissent lorsque l’usage s’intensifie.
Un contrat IA bien rédigé protège autant la décision que la donnée.
Clause 1 – Auditabilité algorithmique
L’auditabilité algorithmique est le socle de toute gouvernance IA sérieuse.
Sans capacité à retracer les versions, les paramètres, les sources et les journaux d’activité, aucune décision produite par le système ne peut être pleinement défendable.
Cette clause vise à garantir que l’organisation conserve un droit de regard effectif sur le fonctionnement du système, tant en régime normal qu’en cas d’incident.
L’objectif n’est pas d’accéder au “cœur technologique” du fournisseur, mais de sécuriser la traçabilité nécessaire à la responsabilité, à la conformité et à la continuité opérationnelle.
Clause 2 – Journalisation & traçabilité des résultats
La journalisation et la traçabilité conditionnent la capacité à expliquer, contrôler et, le cas échéant, contester une décision produite par un système d’IA.
Un outil performant sans mécanisme de logs exploitables ni sources identifiables crée une dépendance opaque.
Cette clause vise à garantir que chaque sortie à portée décisionnelle puisse être retracée : qui a demandé, sur quelles données, avec quelle version du modèle, et selon quels paramètres.
Sans journalisation structurée, il n’y a ni audit, ni investigation d’incident, ni véritable gouvernance.
Clause 3 – Données internes : usage limité & non‑entraînement
La question des données internes est centrale dans tout projet IA.
Un fournisseur ne doit jamais pouvoir réutiliser, entraîner ou améliorer un modèle général à partir des données du Client sans cadre explicite.
Cette clause vise à protéger le patrimoine informationnel de l’organisation : documents, prompts, journaux, configurations et éventuels index/embeddings.
L’objectif est double : éviter toute dilution des données stratégiques et garantir un cloisonnement strict entre clients.
Sans limitation claire d’usage, le risque n’est pas technique, il devient structurel.
Clause 4 – Sous‑traitance, modèle sous‑jacent, localisation
Dans un projet IA, le fournisseur visible n’est pas toujours l’unique acteur technique.
Modèle sous-jacent, infrastructure cloud, sous-processeurs, localisation des traitements : la chaîne réelle peut être plus complexe que le contrat principal.
Cette clause vise à rendre cette chaîne transparente et gouvernable.
Tout changement de sous-traitant, de modèle ou de région d’hébergement peut modifier le niveau de risque juridique, sécuritaire ou réglementaire.
Sans obligation de notification et droit d’objection, l’organisation subit ces évolutions au lieu de les piloter.
La transparence sur l’écosystème technique est une condition préalable à la maîtrise du risque.
Clause 5 – RGPD & transferts hors UE
La conformité RGPD ne se limite pas à la signature d’un DPA.
Dans un projet IA, la question clé porte sur la localisation réelle des traitements et sur les éventuels transferts hors UE/EEE. Infrastructure cloud, support à distance, modèle sous-jacent : les flux peuvent dépasser le périmètre apparent du contrat.
Cette clause vise à sécuriser deux points essentiels :
la maîtrise des données personnelles et la validité des mécanismes de transfert (SCC, analyse d’impact, mesures complémentaires).
Un transfert mal encadré n’est pas un détail juridique.
Il peut remettre en cause la conformité globale du dispositif.
Clause 6 – Réversibilité complète & suppression certifiée
Un projet IA doit pouvoir être arrêté aussi proprement qu’il a été lancé.
La réversibilité ne consiste pas seulement à récupérer des données brutes, mais à restituer l’ensemble des éléments nécessaires à la continuité : historiques, journaux, configurations, index éventuels et documentation d’exploitation.
Cette clause vise à éviter toute dépendance structurelle au fournisseur et à garantir une sortie maîtrisée, techniquement et juridiquement.
La suppression certifiée des copies restantes complète ce dispositif : sans preuve d’effacement, la sortie reste inachevée.
Une IA gouvernable est aussi une IA dont on peut sortir.
Gouvernance post‑contrat
- Monitoring (mensuel) : qualité, coûts à l’usage, incidents, dérives.
- Revue périodique : cas limites, nouveaux risques, plan d’amélioration.
- Change control : mise à jour modèle/version = notification + re‑tests + re‑validation.
- Gestion incidents : runbook + conservation de preuves (logs) + communication.[14]
- Cadre de management : exiger/évaluer une démarche type ISO/IEC 42001 pour structurer responsabilités et amélioration continue. [15]
Références prioritaires et lectures en français
- AI Act (UE 2024/1689) : doc, logs, transparence, robustesse, GPAI, calendrier. [16]
- CNIL : fiches pratiques IA, applicabilité RGPD, sécurité, droits, et AITD/TIA pour les transferts. [17]
- CEPD/EDPB Opinion 28/2024 : anonymisation des modèles et démonstration documentée. [10]
- ANSSI : recommandations de sécurité pour un système d’IA générative. [5]
- CERT-FR : menace IA générative (usage et ciblage). [6]
[1] [3] [4] [9] [11] [14] [16] https://www.senat.fr/europe/textes_europeens/ue0201.pdf
https://www.senat.fr/europe/textes_europeens/ue0201.pdf
[2] [10] https://www.edpb.europa.eu/system/files/2024-12/edpb_opinion_202428_ai-models_en.pdf
https://www.edpb.europa.eu/system/files/2024-12/edpb_opinion_202428_ai-models_en.pdf
[5] https://messervices.cyber.gouv.fr/documents-guides/Recommandations_de_s%C3%A9curit%C3%A9_pour_un_syst%C3%A8me_d_IA_g%C3%A9n%C3%A9rative.pdf
[6] https://www.cert.ssi.gouv.fr/cti/CERTFR-2026-CTI-001/
https://www.cert.ssi.gouv.fr/cti/CERTFR-2026-CTI-001/
[7] [12] https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre4
https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre4
[8] [13] https://www.cnil.fr/fr/analyse-dimpact-des-transferts-des-donnees-la-cnil-publie-la-version-finale-de-son-guide-aitd
[15] https://www.iso.org/fr/standard/42001
https://www.iso.org/fr/standard/42001
[17] https://www.cnil.fr/fr/les-fiches-pratiques-ia
https://www.cnil.fr/fr/les-fiches-pratiques-ia
Lexique – Achats IA
Acronymes & termes réglementaires
AI Act
Règlement européen encadrant l’intelligence artificielle. Il impose des exigences de documentation, transparence, sécurité et gouvernance selon le niveau de risque des systèmes.
RGPD (Règlement Général sur la Protection des Données)
Cadre européen qui régit la collecte, le traitement et la protection des données personnelles.
CNIL
Autorité française de protection des données. Publie des recommandations sur l’IA et le RGPD.
EDPB / CEPD
Comité européen de la protection des données. Émet des avis sur l’application du RGPD, notamment sur les modèles d’IA.
ANSSI
Agence nationale de la sécurité des systèmes d’information. Publie des recommandations de sécurité, notamment pour l’IA.
CERT-FR
Centre gouvernemental de réponse aux incidents cyber en France.
ISO/IEC 42001
Norme internationale de management des systèmes d’intelligence artificielle (gouvernance, risques, amélioration continue).
DPA (Data Processing Agreement)
Accord contractuel encadrant le traitement des données personnelles par un fournisseur.
SCC (Standard Contractual Clauses)
Clauses contractuelles types utilisées pour encadrer les transferts de données hors UE.
AITD / TIA (Analyse d’impact des transferts)
Évaluation des risques liés aux transferts de données hors UE.
Termes achats / IT / IA
RFP (Request for Proposal)
Appel d’offres structuré permettant de comparer des fournisseurs sur la base d’exigences formalisées.
Scorecard
Grille d’évaluation multicritère utilisée pour comparer objectivement les fournisseurs.
Checklist
Liste de contrôle permettant de s’assurer que tous les éléments clés sont couverts dans un projet ou un appel d’offres.
Run
Phase d’exploitation opérationnelle d’une solution après son déploiement.
Go / No Go
Décision de validation ou d’abandon d’un projet sur la base de critères objectifs.
Change control
Processus de gestion des modifications (ex : changement de modèle IA, version, architecture).
Runbook
Documentation opérationnelle décrivant les procédures à suivre en cas d’incident ou en exploitation.
Termes techniques IA
IA (Intelligence Artificielle)
Ensemble de technologies permettant à des systèmes d’effectuer des tâches nécessitant habituellement une intelligence humaine.
IA générative (GENEX)
Type d’IA capable de produire du contenu (texte, image, code). Ex : modèles de langage.
Modèle d’IA
Algorithme entraîné sur des données permettant de produire des prédictions ou du contenu.
Modèle à usage général (GPAI)
Modèle d’IA générique pouvant être utilisé pour plusieurs cas d’usage (ex : grands modèles de langage).
Prompt
Instruction donnée à un modèle d’IA pour générer une réponse.
Hallucination
Réponse incorrecte ou inventée générée par un modèle d’IA, présentée comme plausible.
Auditabilité algorithmique
Capacité à analyser et vérifier le fonctionnement d’un système d’IA (versions, paramètres, décisions).
Traçabilité
Capacité à retracer l’origine d’une décision ou d’un résultat produit par l’IA.
Journalisation (logs)
Enregistrement des actions, requêtes et résultats d’un système pour analyse et audit.
Rejouabilité
Capacité à reproduire une réponse d’IA à partir des mêmes conditions (données, modèle, paramètres).
Fine-tuning (réentraînement du modèle)
Adaptation d’un modèle d’IA à un cas d’usage spécifique à partir de données supplémentaires, pouvant entraîner des impacts en termes de coûts, de dépendance fournisseur et de gestion des données.
Termes techniques infrastructure & coûts
API (Application Programming Interface)
Interface permettant à des applications de communiquer avec un service (ex : appeler un modèle IA).
Token
Unité de mesure utilisée par certains modèles d’IA pour facturer l’usage (basée sur la quantité de texte traité).
RAG (Retrieval-Augmented Generation)
Technique combinant recherche de documents internes et génération de réponse par IA.
Stockage vectoriel
Base de données permettant de stocker des représentations numériques de documents pour les recherches IA.
GPU (Graphics Processing Unit)
Processeur utilisé pour les calculs intensifs nécessaires à l’IA.
Batch
Traitement de données en masse, en différé.
Contexte long
Capacité d’un modèle à traiter de grandes quantités de texte en entrée.
Sécurité & données
Données internes
Informations propres à l’organisation (documents, bases de données, emails, etc.).
Sous-traitant / sous-processeur
Entité utilisée par le fournisseur pour traiter des données ou exécuter une partie du service.
Transfert de données
Déplacement de données en dehors d’un territoire (ex : hors UE).
Localisation des données
Lieu physique ou juridique où sont stockées et traitées les données.
Cloisonnement des données
Séparation stricte des données entre clients ou environnements.
Contractuel & gouvernance
Réversibilité
Capacité à quitter un fournisseur en récupérant ses données et en assurant la continuité du service.
Suppression certifiée
Garantie contractuelle que les données ont été définitivement supprimées chez le fournisseur.
Responsabilité
Répartition des obligations et des risques entre client et fournisseur.
Gouvernance
Organisation des rôles, responsabilités et processus de pilotage du système IA.
Mode dégradé
Fonctionnement du système sans IA en cas d’incident ou d’indisponibilité.
