Modèle de CCTP pour l'acquisition d'une IA souveraine : clauses types, critères d'exclusion et commande publique

Pour les acheteurs publics, les directions des systèmes d’information (DSI) ministérielles, les centres hospitaliers universitaires (CHU) et les collectivités territoriales, acquérir un système d’intelligence artificielle générative relève du parcours du combattant juridique.

D’un côté, la circulaire n° 6282/SG du Premier ministre relative à la doctrine d’utilisation de l’informatique en nuage par l’État (“Cloud au Centre”) et les avis successifs de la CNIL et de la DINUM imposent une étanchéité absolue vis-à-vis des législations extraterritoriales (notamment la section 702 du Foreign Intelligence Surveillance Act - FISA et le CLOUD Act américain).

D’un autre côté, le Code de la commande publique (articles L. 3 et L. 2152-7) interdit toute discrimination injustifiée ou mention de marques propriétaires dans le Cahier des Clauses Techniques Particulières (CCTP), sous peine de recours en référé précontractuel devant le juge administratif.

Comment rédiger un cahier des charges irréprochable qui impose des exigences de souveraineté et de résilience sans violer le principe de libre accès à la commande publique ?

Ce dossier fournit les clauses types opposables, les critères d’évaluation pondérés et la doctrine juridique à insérer dans vos dossiers de consultation des entreprises (DCE).

flowchart TD
    A[Besoin Public : Système RAG Métier] --> B{Rédaction du DCE / CCTP}
    B --> C[Clause 1 : Étanchéité Réseau & Air-Gap]
    B --> D[Clause 2 : Immunité aux Lois Extraterritoriales FISA / CLOUD Act]
    B --> E[Clause 3 : Auditabilité du Code & Licence Open-Source]
    B --> F[Clause 4 : Anonymisation PII en RAM Volatile]

    C & D & E & F --> G[Grille de Notation Pondérée des Offres]
    G --> H{Analyse des Candidatures}
    H -->|Solution SaaS US / API Cloud Dépendante| I[❌ Offre Irrecevable ou Note Zéro sur Souveraineté]
    H -->|Architecture On-Premise / Yevi Core v1.0| J[✅ Attribution Conforme Code Commande Publique]

    style I fill:#f87171,stroke:#b91c1c,color:#fff
    style J fill:#10b981,stroke:#047857,color:#fff

---

1. Justification juridique des exigences de souveraineté dans le CCTP

L’acheteur public a le droit d’imposer des contraintes techniques très strictes dès lors qu’elles sont objectivement justifiées par l’objet du marché ou ses conditions d’exécution (Article L. 2112-2 du Code de la commande publique).

Pour blinder le CCTP contre les contestations des grands intégrateurs cloud :

1. Le rattachement au secret des données publiques

Les collectivités territoriales et administrations traitent par nature des données couvertes par des secrets protégés par la loi :

• Les données fiscales et sociales des administrés (secret fiscal, secret professionnel des agents publics - art. 226-13 du Code pénal) ;
• Les délibérations stratégiques des assemblées et marchés avant publication ;
• Les données de santé des patients dans les hôpitaux publics (certifications HDS) ;
• Les dossiers d’aide sociale à l’enfance et d’état civil.

L’obligation de retenir une solution hébergée exclusivement au sein du réseau de la personne publique (ou sur un cloud certifié SecNumCloud 3.2 sans transfert transfrontalier) constitue une mesure de sécurité proportionnée au sens de l’Article 32 du RGPD et du référentiel général de sécurité (RGS).

---

2. Les 4 clauses indispensables à intégrer dans votre CCTP

Voici la formulation juridique exacte à copier dans votre document de consultation :

Article 4.1 du CCTP : Exigence d’isolement réseau et mode déconnecté (Air-Gapped)

“Le titulaire du marché doit fournir une solution logicielle d’intelligence artificielle générative et de recherche documentaire (RAG) capable de s’exécuter de manière 100 % autonome sur l’infrastructure matérielle fournie par la personne publique (mode On-Premise) ou au sein d’une enclave réseau dédiée. La solution ne doit requérir aucun flux réseau sortant vers l’Internet public pour son fonctionnement opérationnel (ni pour l’inférence des modèles de langage, ni pour le calcul des vecteurs d’embeddings, ni pour la télémétrie ou la vérification de licences). Toute solution nécessitant l’appel à une API tierce hébergée en dehors du réseau de la collectivité entraînera l’élimination immédiate de l’offre pour non-conformité aux exigences techniques minimales.”

Article 4.2 du CCTP : Immunité juridique aux droits extraterritoriaux tiers

“Afin de garantir le respect du secret professionnel et la protection des données sensibles des administrés, le titulaire du marché, ses sous-traitants directs et les éditeurs des composants logiciels sous-jacents ne doivent pas être soumis, directement ou indirectement, à des obligations de divulgation ou de communication de données imposées par des autorités administratives ou judiciaires d’États tiers à l’Union Européenne (notamment en application du Foreign Intelligence Surveillance Act - section 702 ou du CLOUD Act américain). Le titulaire fournira une attestation sur l’honneur certifiant l’indépendance capitalistique et opérationnelle de la chaîne de traitement vis-à-vis des juridictions extraterritoriales précitées.”

Article 4.3 du CCTP : Auditabilité du code source et utilisation de modèles ouverts

“Pour répondre aux exigences de transparence de l’action publique et de l’EU AI Act, la solution proposée doit reposer sur un cœur applicatif dont le code source est auditable par la DSI de la personne publique. Les modèles de fondation déployés (LLMs) doivent être des modèles sous licence ouverte permissive (de type Apache 2.0, MIT ou OpenRAIL), permettant la vérification des poids et la maîtrise totale des paramètres d’inférence. Les solutions ‘boîte noire’ (Black Box) propriétaires dont les poids ou le code ne sont pas consultables seront pénalisées dans la notation technique.”

Article 4.4 du CCTP : Anonymisation en mémoire vive volatile (Privacy Vault)

“La solution doit obligatoirement intégrer un module d’anonymisation préalable et temps réel des données à caractère personnel (noms, adresses, numéros NIR, données financières) avant toute injection dans le prompt de contexte vectoriel. Ce masquage doit s’opérer en mémoire vive volatile (RAM) chiffrée selon le standard AES-256-GCM, avec destruction immédiate des correspondances dès la fin de la session de requête (principe de minimisation du RGPD).”

---

3. Grille d’évaluation et critères de notation pondérés (Règlement de Consultation)

Pour attribuer légalement le marché au candidat offrant la meilleure garantie de souveraineté, le Règlement de la Consultation (RC) doit pondérer les critères de la manière suivante :

[ PONDÉRATION DE L'OFFRE (100 POINTS) ]
├── Critère 1 : Prix global forfaitaire et TCO sur 3 ans (40 points)
└── Critère 2 : Valeur technique et souveraineté de l'architecture (60 points)
    ├── Sous-critère 2.1 : Étanchéité réseau Air-Gap & Zéro flux externe (20 points)
    ├── Sous-critère 2.2 : Robustesse RAG & Ancrage strict anti-hallucination (15 points)
    ├── Sous-critère 2.3 : Conformité RGPD, gestion des permissions RBAC/LDAP (15 points)
    └── Sous-critère 2.4 : Pérennité open-source & Absence de vendor lock-in (10 points)

Barème de notation du sous-critère “Souveraineté & Étanchéité” (20 points)

• 20 / 20 : Solution 100 % locale, exécutée en conteneurs durcis sur le matériel de la collectivité (ou Appliance dédiée), zéro paquet internet, code source ouvert sous licence MIT (architecture Yevi Core v1.0).
• 10 / 20 : Solution hébergée sur un cloud européen souverain certifié SecNumCloud, mais dépendant d’un lien réseau externe obligatoire.
• 0 / 20 : Solution s’appuyant sur des API managées d’hyperscalers américains ou soumise au CLOUD Act (Offre éliminée pour non-conformité aux exigences minimales du CCTP).

---

4. Pourquoi Yevi Core v1.0 répond à 100 % des exigences de la commande publique

L’architecture de Yevi Core v1.0 a été spécialement conçue pour s’aligner sur les exigences de l’État et des collectivités territoriales :

Exigence Commande Publique	Réponse Native Yevi Core v1.0
Licence Logicielle	Licence MIT (Open-Source) : Zéro redevance logicielle récurrente, pérennité garantie pour la collectivité.
Hébergement & Matériel	Mode BYOH (Bring Your Own Host) sur serveurs existants de la collectivité, VPS souverain dédié ou Appliance physique Yevi Box (R&D en cours avec liste d’attente ouverte).
Compatibilité Annuaire	Synchronisation native Active Directory / LDAP pour respecter les droits d’accès des agents publics (voir guide RBAC).
Preuve de Souveraineté	Journaux JSONL signés cryptographiquement attestant du traitement 100 % intra-muros sans appel sortant.

---

5. Accompagnement à la rédaction pour les acheteurs publics

Nos consultants seniors et juristes accompagnent régulièrement les directions juridiques et les services des marchés publics dans :

• La relecture et l’ajustement de vos CCTP et Règlements de Consultation ;
• La réalisation préalable d’un Proof of Concept (POC) de 14 jours permettant d’éprouver la charge sur vos propres documents administratifs avant lancement du marché public (découvrir nos prestations) ;
• Le calcul de l’estimation budgétaire sincère pour vos autorisations d’engagement (AE) et crédits de paiement (CP).

---

🛠️ Ressources & Documentation Commande Publique

• 🎯 Demander un Cadrage Marché Public avec notre Équipe Juridique (30 min)
• 💻 Accéder au Répertoire Open Source Yevi Core v1.0 sur GitHub
• 📄 Télécharger le Livre Blanc Officiel DORA, RGPD & Commande Publique
• 🏛️ Consulter les solutions pour Ministères et Collectivités Territoriales