Réversibilité & portabilité
La réversibilité ne consiste pas à partir. Elle consiste à savoir, avant de signer, ce qu'il faudrait faire pour partir et combien de temps cela prendrait. Une adhérence nommée et chiffrée est une décision ; la même, découverte le jour du départ, est un incident.
Un plan de sortie qui n'a jamais été joué est une intention.
Personne ne construit une plateforme en prévoyant de la quitter, et c'est précisément pour cela que la question ne se pose jamais au bon moment. Elle arrive quand un fournisseur change ses conditions, quand un rachat déplace l'hébergement, quand une direction demande où se trouvent réellement les données. À cet instant, la seule chose qui compte est de savoir ce qu'il faudrait faire pour partir, et combien de temps cela prendrait.
Nous rendons cette réponse disponible avant qu'on en ait besoin. Des adhérences nommées, classées et chiffrées plutôt qu'évitées par principe : un service managé qui fait gagner des mois à une équipe d'exploitation vaut son adhérence, encore faut-il l'avoir écrite quelque part. Des clauses qui listent nominativement ce qui s'exporte. Et un exercice joué sur le volume réel, parce que ce qu'un plan de sortie sous-estime n'est presque jamais l'export : c'est tout ce qui doit être reconstruit au lieu d'être transféré.
Ce que nous faisons
Quatre chantiers pour que partir reste une décision, et non un projet que personne n'ose lancer.
Nommer les adhérences
Chaque service managé, chaque format propriétaire et le modèle d'habilitation listés, avec ce qu'il en coûterait de les quitter. Une adhérence n'est pas un défaut : c'est un choix qu'il faut connaître et réviser, pas découvrir.
classée : acceptée, à réduire, ou interdite
- Une ligne par service managé, avec son issue
- Les formats propriétaires, et l'export s'il existe
- Le modèle d'habilitation décrit hors console
Des fondations portables
Une infrastructure décrite en code, des protocoles ouverts, des images de conteneurs et des données dans des formats lisibles sans l'outil qui les a produites. Ce qui est décrit se rejoue ailleurs ; ce qui vit dans une interface ne se rejoue pas.
portabilité prouvée sur une seconde cible, pas affirmée
- Infrastructure en code, rejouée sur une seconde cible
- Protocoles ouverts partout où un équivalent existe
- Données lisibles sans l'outil d'origine
Des clauses qui disent quelque chose
Le périmètre exportable listé nominativement, un format ouvert et documenté, un délai mesuré au volume réel et une assistance à la sortie chiffrée plutôt que promise. Le règlement pose un plancher ; le contrat doit l'appliquer à votre parc.
négociées au renouvellement, pas au départ
- Périmètre exportable listé nominativement, pas par catégorie
- Délai mesuré au volume réel, pas au volume d'un pilote
- Assistance à la sortie chiffrée, avec un interlocuteur nommé
Éprouver la sortie
La bascule exécutée sur le volume réel, les durées mesurées, le retour arrière écrit et joué. Un exercice trouve en général un délai plutôt qu'un blocage, et un délai trouvé à l'avance se négocie.
rejoué à chaque renouvellement de contrat
- La bascule exécutée sur le volume de production
- Ce qui se reconstruit compté à part de ce qui s'exporte
- Un retour arrière écrit, puis réellement joué
Ce que vous recevez
Un même projet traverse les quatre livrables ci-dessous : préparer puis éprouver un plan de sortie. Chaque ligne dit ce qui est réellement remis, dans l'ordre où il l'est.
L'inventaire des adhérences
Les services managés, les formats propriétaires et le modèle d'habilitation, chacun avec son coût de sortie et son classement : acceptée, à réduire, interdite. La plus souvent oubliée est le modèle d'habilitation qui n'existe que dans une console.
Les clauses à obtenir
Le périmètre exportable listé nominativement, un format ouvert lisible sans l'outil d'origine, un délai mesuré au volume réel et une assistance à la sortie chiffrée. Le règlement est le plancher, pas le contrat.
La procédure de bascule
Une séquence écrite pour être exécutée plutôt que lue, avec des critères de réussite qui exigent le même niveau de service et pas seulement un système qui démarre, et un retour arrière qui existe avant la première étape.
L'exercice, sur le volume réel
L'export tient en quatre jours. Ce que l'exercice trouve, ce sont les dix-neuf jours de reconstruction que personne n'avait comptés dans une fenêtre de trente jours : une durée à négocier, pas un blocage.
Comment on travaille
Inventorier
selon le nombre de services managés et l'ancienneté des contrats
- Les adhérences nommées, classées et chiffrées
- Les formats propriétaires et leur issue documentée
- Le modèle d'habilitation, décrit hors console
Contractualiser
selon la marge de négociation et l'échéance des renouvellements
- Périmètre exportable listé nominativement
- Format ouvert et délai mesurés au volume réel
- L'assistance à la sortie chiffrée, pas promise
Éprouver
selon le volume de données et ce qui se reconstruit au lieu de se transférer
- La bascule exécutée sur le volume réel
- Les durées mesurées, y compris les reconstructions
- Le retour arrière écrit et joué
Maintenir
engagement de service défini avec vous
- L'inventaire révisé à chaque nouveau service
- L'exercice rejoué à chaque renouvellement
- Les écarts traités avant la prochaine échéance
Libre de bouger, et rarement obligé de le faire
La réversibilité sert rarement et se garde toujours. Une plateforme qu'on pourrait quitter est une plateforme depuis laquelle on négocie, et l'essentiel de ce qui la rend quittable la rend d'abord plus simple à exploiter.
Une adhérence qu'on a nommée. Chaque service managé et chaque format propriétaire listés avec leur coût de sortie, classés et révisés à chaque renouvellement plutôt qu'évités par principe.
Des plateformes bâties pour pouvoir être quittées
Une chaîne de livraison décrite en code plutôt qu'en scripts
18 squads sur une même chaîne · −72 % de time-to-market
Des pipelines Jenkins historiques, des scripts shell propriétaires et des déploiements manuels accumulés au fil des ans : rien qui puisse se rejouer ailleurs, et une mise en production qui prenait plusieurs jours.
Une chaîne reconstruite sur Terraform, Ansible, Docker et Kubernetes, avec les contrôles de conformité câblés dans le pipeline. Ce qui est décrit en code se rejoue sur un autre socle ; ce qui vit dans une console ne se rejoue nulle part.
Quatorze modules, des briques ouvertes, hébergés en France
14 modules en production · 100 % open source
Un outillage informel de tableurs et d'outils SaaS gratuits qui ne tenait plus le volume, sur des données de mineurs, avec un budget associatif qui excluait les licences propriétaires récurrentes.
Un système d'information modulaire bâti sur Postgres, Symfony, Strapi, Metabase et Mailtrain, hébergé en France et conforme RGPD et WCAG 2.1 AA. Des formats ouverts et des briques documentées, pour que rien ne soit retenu par une licence.
Insights & Perspectives
Kubernetes ou Docker : deux technologies de conteneurs à ne pas opposer
Docker empaquette les applications en conteneurs, Kubernetes les orchestre à grande échelle : deux briques complémentaires du pipeline DevOps, pas des rivales.
Stratégies d'adoption du cloud
L'adoption du cloud ne se pose plus en termes de faisabilité. Réussir suppose d'aligner la technologie sur les objectifs métier : sept stratégies pour adopter le cloud avec méthode.
Sauvegarde et restauration cloud : bâtir une stratégie de cyber-résilience
Règle 3-2-1-1-0, immutabilité, RPO et RTO : le guide d'une stratégie de reprise réellement éprouvée plutôt que seulement documentée.
Connaissez la sortie avant d'en avoir besoin
Des adhérences nommées et chiffrées, des clauses mesurées au volume réel, et un plan de sortie joué une fois plutôt qu'écrit deux fois.
Questions fréquentes
Non, parce qu'un contrat fixe un délai et ne dit jamais ce qui tient dedans. Le cadre européen plafonne désormais les préavis et les périodes de transition, ce qui est un plancher utile. Ce que ni le règlement ni le contrat ne mesurent, c'est le temps que vos données mettent à sortir, et la part qu'il faut reconstruire à la place.
Non. Un service managé qui fait gagner des mois à une équipe d'exploitation vaut son adhérence. Ce qui compte est de savoir lesquels ont un équivalent ailleurs, lesquels devraient être reconstruits, et combien de temps cette reconstruction prend à votre volume.
Rarement comme architecture permanente. Tourner partout à la fois multiplie le coût et la charge d'exploitation pour une liberté qui sert une fois. Ce qui tient réellement, c'est une plateforme unique décrite en code, dont on a prouvé qu'elle se rejoue sur une seconde cible.
Une durée, pas un blocage. L'export est rarement le problème. Ce qui surprend, c'est tout ce qui doit être reconstruit au lieu d'être transféré, un index de recherche ou un modèle dérivé, qui peut consommer à lui seul l'essentiel d'une fenêtre de transition de trente jours.
Le modèle d'habilitation. Identités, rôles et droits n'existent souvent que dans la console d'un fournisseur, donc ne se rejouent pas ailleurs. Les données reviennent et plus personne ne peut être autorisé à s'en servir, ce qui arrête un changement aussi sûrement qu'un format propriétaire.
Au renouvellement, jamais au départ. Un fournisseur à qui l'on demande un engagement de sortie chiffré pendant qu'un contrat se signe ne répond pas de la même façon que celui à qui on le demande une fois que le client a annoncé qu'il partait.
L'inventaire prend 2 à 6 semaines selon le nombre de services managés et l'ancienneté des contrats, et produit les adhérences nommées, les formats propriétaires avec leur issue et le modèle d'habilitation décrit hors console. Les clauses et un premier exercice suivent en 4 à 10 semaines.