Pourquoi cette mesure ?
Une clause de réversibilité écrite dans un contrat ne garantit pas que l’administration sait réellement quitter son prestataire. Les dépendances les plus coûteuses apparaissent souvent après plusieurs années : formats propriétaires, modèles entraînés difficiles à exporter, scripts non documentés, équipes ayant perdu la compétence interne ou frais de sortie dissuasifs. La mesure 9.04 impose donc une réversibilité testable. Le délai de douze mois constitue une cible maximale de transition pour les contrats les plus complexes, pas une permission d’attendre un an pour les opérations simples.
État des lieux en 2026 : partir de ce qui existe vraiment
Le droit de la commande publique fournit déjà un socle beaucoup plus avancé qu’une simple intention. Le CCAG-TIC 2021 définit la réversibilité et la transférabilité et prévoit un plan décrivant les conditions techniques et organisationnelles du retour ou du transfert de responsabilité. Il mentionne notamment les formats documentés, interfaces, documentation et éléments nécessaires à la reprise. La mesure L’analyse doit donc renforcer et systématiser ces exigences, pas prétendre qu’elles n’existent pas. Le changement consiste à faire du test de sortie un critère de recette et d’audit périodique.
Source au point d’usage : CCAG-TIC — réversibilité et transférabilité ↗
Concevoir, financer et sécuriser la mise en œuvre
Architecture, fonctionnement et conditions techniques
Chaque marché numérique critique doit contenir un inventaire des données, configurations, journaux, modèles, prompts, règles métier, codes ou scripts remis en sortie. Les formats doivent être documentés et exploitables sans l’outil du titulaire. Un environnement de reprise doit être testé avant la dernière année du contrat. Pour une plateforme d’IA, la réversibilité inclut aussi les embeddings, bases vectorielles, paramètres de routage et évaluations. L’administration doit pouvoir remplacer le modèle sans perdre l’historique de validation ou les métriques de qualité.
Démonstration financière : séparer coût, capacité et économie
Le coût de sortie est un prix du contrat et doit être intégré au coût total de possession dès l’attribution. Une offre moins chère à l’entrée peut être plus coûteuse si la migration de sortie mobilise des mois de prestation. Le dossier propose de publier : coût estimé de réversibilité, plafond contractuel des prestations de sortie, ressources internes nécessaires et coût d’une double exploitation temporaire. Le bénéfice financier est principalement un risque évité ; on ne le transforme pas en économie annuelle fictive. Une économie n’est reconnue que lorsqu’un nouveau marché ou une internalisation réduit effectivement une dépense.
Droit applicable et limites à ne pas franchir
Le CCAG-TIC fournit une base contractuelle, mais les documents particuliers du marché doivent préciser les éléments propres au service. Les obligations doivent rester compatibles avec les droits de propriété intellectuelle et les licences utilisées. Une administration ne peut pas exiger la remise d’un actif qu’elle n’a pas acquis ou dont le titulaire n’a pas le droit de céder les droits ; elle peut en revanche prévoir des formats et interfaces permettant la continuité. Pour les données personnelles, la restitution et l’effacement en fin de contrat doivent être articulés avec le RGPD et la conservation légale.
Plans A, B et C : l’objectif survit au blocage d’une voie
clause standard obligatoire pour les nouveaux marchés critiques et test de réversibilité avant renouvellement.
pour les contrats existants, négocier un avenant ou imposer au minimum un inventaire de sortie et des exports documentés lors du prochain acte contractuel possible.
si un système propriétaire ne peut être rendu suffisamment réversible, réduire progressivement son périmètre et construire une couche d’abstraction autour de lui pour empêcher de nouvelles dépendances. L’objectif n’est pas de rompre tous les contrats, mais de ne plus signer sans sortie praticable.
Risques, objections et garde-fous
La réversibilité peut devenir une formalité documentaire si personne ne teste les exports. À l’inverse, une exigence trop large peut obliger les fournisseurs à livrer des secrets industriels sans rapport avec la continuité. Le test doit donc être orienté résultat : un tiers désigné peut-il reprendre le service avec les données, configurations et interfaces prévues ? Les marchés les plus critiques peuvent utiliser une simulation annuelle ou bisannuelle. La qualité des documents de sortie doit être vérifiée par des équipes qui ne sont pas celles du titulaire.
Indicateurs, audit et preuve de réussite
Indicateurs : part des marchés critiques avec plan de réversibilité ; part testée dans les vingt-quatre derniers mois ; nombre de dépendances propriétaires sans alternative ; durée observée d’un export complet ; coût de sortie ; anomalies découvertes lors des tests ; part de contrats comportant un plafond des frais de sortie ; délai de reprise par un prestataire tiers ; taux d’éléments de documentation remis à jour.
Transformer la réversibilité contractuelle en exercice réellement testé
Une clause de réversibilité n’a de valeur que si l’on sait l’exécuter. Le contrat doit préciser les formats d’export, la documentation, les interfaces, l’assistance du titulaire, les délais, les coûts et le sort des données résiduelles. Mais il faut surtout programmer des tests pendant la vie du marché.
Un échantillon de données et de configurations est exporté, restauré dans un environnement de secours et contrôlé. Les anomalies sont corrigées avant la fin du contrat, lorsque le prestataire dispose encore des équipes et des incitations nécessaires. Cette approche transforme la réversibilité d’une promesse juridique en capacité opérationnelle. Elle est cohérente avec le CCAG-TIC, qui encadre déjà la réversibilité : la réforme consiste à systématiser sa préparation et sa preuve sur les services numériques critiques. [source]
Distinguer données, modèles, configurations et connaissances
Quitter un fournisseur d’IA ne signifie pas seulement récupérer une base de données. Il faut inventorier les prompts système, règles métier, évaluations, paramètres, index vectoriels, journaux, modèles éventuellement adaptés, scripts de préparation, listes de contrôle et documentation d’exploitation. Certains éléments appartiennent à l’administration ; d’autres relèvent d’une licence ou d’un service propriétaire.
Le marché doit déterminer ces droits avant le démarrage. Lorsque la portabilité complète est impossible, l’administration doit savoir quel travail devra être reconstruit et chiffrer ce coût. Cette cartographie évite la situation où les données sont théoriquement exportables mais où la logique accumulée pendant cinq ans reste enfermée dans un environnement que personne ne sait reproduire.
Le délai de douze mois comme plafond de préparation, pas comme attente systématique
La référence à douze mois doit être interprétée comme une exigence maximale de préparation pour des systèmes complexes, pas comme un prétexte pour attendre la dernière année du marché. La trajectoire de sortie commence dès la conception. À intervalles réguliers, l’administration met à jour son inventaire, vérifie les exports et maintient la documentation.
Lors d’un changement planifié, la bascule peut alors être beaucoup plus courte. Pour une application simple, quelques semaines peuvent suffire ; pour une plateforme critique avec des dizaines d’interfaces, une période plus longue est nécessaire. Le contrat doit définir des jalons proportionnés. Cette approche évite de transformer une durée politique uniforme en contrainte techniquement absurde pour des systèmes très différents.
Calculer le coût de sortie avant de comparer les offres
Lors d’un appel d’offres, le coût de sortie doit entrer dans l’analyse économique. Il comprend les prestations de réversibilité, la migration, la double exploitation temporaire, les tests, les licences de transition et la formation. Deux offres ayant le même prix annuel peuvent avoir des coûts de sortie radicalement différents.
La comparaison peut donc utiliser un coût total sur le cycle de vie : acquisition plus exploitation plus évolution plus sortie. Ce calcul ne doit pas supposer qu’un changement de fournisseur aura lieu à coup sûr ; il doit présenter des scénarios. La réversibilité devient ainsi une assurance mesurable. Son coût peut être accepté comme prix de la liberté de choix, mais il ne doit pas être dissimulé ni découvert seulement lorsque l’administration souhaite partir.
Sanctionner l’irréversibilité constatée sans mettre le service en danger
Si un test révèle qu’un prestataire ne peut pas fournir les éléments promis, la réponse doit être graduée : plan correctif, nouveau test, retenue ou pénalité lorsque le contrat le prévoit, puis limitation des nouveaux développements dépendants. Résilier immédiatement un service critique peut parfois aggraver le risque. La priorité est de restaurer la capacité de sortie tout en assurant la continuité.
Les nouveaux marchés doivent tirer les leçons des incidents : formats, délais et responsabilités sont précisés. Un registre interne des difficultés de réversibilité permet aux acheteurs publics de ne pas répéter les mêmes clauses insuffisantes. Le succès de 9.04 se mesure au nombre de sorties testées et réussies, pas au nombre de contrats contenant simplement le mot « réversibilité ».
Approfondissement opérationnel et conditions de réussite
Déclencher réellement la réversibilité : prévoir le jour où le contrat se termine mal
Une clause de réversibilité n’a de valeur que si l’administration sait quand et comment l’activer. Le contrat définit les événements déclencheurs : arrivée normale à échéance, défaillance de service, changement de stratégie, risque de sécurité, perte de qualification ou évolution économique majeure. Il précise aussi qui décide, quelles équipes sont mobilisées et dans quel ordre les données, journaux, configurations et clés sont transférés. Un calendrier de sortie est testé au moins une fois pendant la vie du marché sur un périmètre représentatif. Cette répétition permet de découvrir avant la crise les dépendances cachées, les formats non documentés ou les coûts de transfert oubliés. Le plan de réversibilité devient ainsi une procédure opérationnelle et non une annexe juridique jamais utilisée.
Mesurer le coût complet du verrouillage fournisseur
Le prix annuel du service ne suffit pas à comparer deux offres. Le coût complet intègre la migration initiale, l’exploitation, les licences, les compétences spécifiques, les interfaces propriétaires, le stockage sortant, la récupération des historiques et la future migration. Une solution légèrement plus chère à l’année peut être préférable si elle réduit fortement le coût et le risque de sortie. Inversement, une offre d’entrée très basse peut devenir coûteuse après accumulation de données et dépendances. Le dossier financier publie donc deux horizons : coût de fonctionnement et coût de sortie simulé. Cette approche interdit de présenter comme économie un rabais commercial qui ne serait obtenu qu’en échange d’une dépendance durable. La concurrence doit rester possible pendant toute la vie du service.
Inventorier toutes les dépendances avant de rédiger la clause de sortie
La réversibilité échoue souvent sur des éléments oubliés : identités, scripts d’exploitation, historiques, fichiers de configuration, modèles personnalisés, index de recherche, clés, tableaux de bord, procédures de support ou connaissances détenues par une équipe externe. Le dossier de réversibilité maintient un inventaire de ces dépendances pendant le contrat. Chaque élément indique son format de restitution, son propriétaire et le temps estimé de migration. L’inventaire est mis à jour lors d’une évolution significative. Cette approche évite que la clause juridique promette la restitution des seules données alors que la reprise réelle nécessite des dizaines d’éléments supplémentaires. Elle permet également d’estimer le coût de sortie et d’identifier très tôt une dépendance qui deviendrait disproportionnée.
Contrôler l’exhaustivité des exports avec des tests de restauration
Recevoir un fichier d’export ne prouve pas qu’il est exploitable. Le test de réversibilité vérifie qu’un environnement distinct peut relire les données, reconstruire les relations essentielles, récupérer les métadonnées et reproduire les fonctions nécessaires à la continuité. Des contrôles d’intégrité comparent volumes, enregistrements et historiques. Les erreurs sont corrigées avant que la situation ne devienne urgente. Pour les plateformes complexes, une restauration partielle annuelle peut suffire à tester la chaîne, complétée par un exercice plus large avant échéance. Cette procédure transforme la réversibilité en capacité démontrée. Elle permet aussi de négocier les formats pendant que le fournisseur est encore pleinement engagé dans le marché et non après sa fin.
Prévoir une période de double fonctionnement pour les services critiques
La bascule immédiate d’un prestataire à un autre peut provoquer une rupture de service, même lorsque l’export est correct. Pour les fonctions critiques, le planning prévoit une période limitée pendant laquelle l’ancien et le nouvel environnement fonctionnent en parallèle ou se répartissent les usages. Les résultats sont comparés et un point de non-retour explicite est défini. Cette coexistence a un coût, qui doit apparaître dans le budget de sortie. Elle ne doit pas devenir une prolongation indéfinie du fournisseur sortant. Le contrat précise donc les prestations attendues pendant la transition, les délais de réponse et la fin des accès. La réversibilité devient une transition planifiée et contrôlée plutôt qu’un saut technique au dernier jour du contrat.
Associer pénalités et coopération sans mettre la continuité en otage
Une pénalité peut inciter le fournisseur à respecter ses obligations de sortie, mais elle ne remplace pas un dispositif opérationnel. Les sanctions sont proportionnées aux retards ou défauts constatés et conçues pour ne pas inciter à une rupture brutale de coopération. Les prestations de réversibilité importantes sont jalonnées : documentation, premier export, test, correction, transfert final et suppression des copies. Le paiement peut être lié à ces étapes. En cas de défaillance grave, l’administration dispose de droits d’accès ou d’assistance prévus au contrat. Cette architecture contractuelle évite le faux choix entre accepter une sortie dégradée et déclencher un conflit qui mettrait le service en danger. La continuité du service reste prioritaire tout en rendant les obligations réellement opposables.
Réversibilité numérique : faire du test de sortie une obligation contractuelle
Une clause de réversibilité sans exercice pratique est insuffisante
Le contrat doit préciser formats d’export, documentation, délais, assistance, coût maximal et destruction des copies. Mais ces éléments restent théoriques tant qu’un export réel n’a pas été réalisé et réimporté dans un environnement tiers.
Le marché peut imposer un test avant la moitié de sa durée puis avant renouvellement.
Mesurer les dépendances qui ne se voient pas dans les données
La sortie concerne aussi identités, scripts, modèles de sécurité, observabilité, configurations réseau et compétences humaines. Un service peut exporter ses fichiers et rester pourtant incapable de fonctionner ailleurs.
Le plan de réversibilité doit donc couvrir la pile technique et les procédures d’exploitation.
Créer un coût de sortie prévisible
Les prestations nécessaires à la migration doivent être tarifées ou plafonnées dès l’appel d’offres afin d’éviter qu’un fournisseur rende le départ économiquement prohibitif. Le coût estimé peut entrer dans la comparaison des offres au même titre que le prix d’exploitation.
Un indice de réversibilité permet ensuite de suivre la dette technique créée pendant le contrat.
Sources primaires et institutionnelles
Les affirmations de droit ou d’état de l’art ci-dessus sont rattachées à des sources publiques. Les hypothèses propres au Plan Delta-Sierra sont signalées comme propositions et ne sont pas présentées comme des chiffres officiels.
- CCAG-TIC — réversibilité et transférabilité ↗
- CCAG-TIC — définition et plan de réversibilité ↗
- Albert API — interface multi-modèles ↗
Date de vérification : 12 août 2026. Le cadre de l’IA évolue rapidement ; les dates d’application du règlement européen sont vérifiées contre le règlement (UE) 2026/1744.