Un agent de l'administration ouvre un tableur.
Ça marche.
Un collègue entre dans une visio.
Ça marche.
Quelqu'un retouche un texte, fouille une archive de courriels, vise une facture, envoie une présentation, pose une réunion.
Tout marche.
Des milliers de personnes font cela des millions de fois par jour.
La souveraineté n'effleure personne.
Et c'est peut-être tant mieux.
Une infrastructure qui tient est faite pour s'effacer.
Plus elle est sûre, moins on la regarde. Les écrans deviennent familiers. Les gestes, automatiques. D'autres systèmes s'y branchent. Le savoir s'y agrège. Les nouveaux arrivants l'apprennent. Les procédures la tiennent pour acquise.
À force, ce n'est plus un choix d'outil.
C'est simplement la façon dont la maison travaille.
C'est alors qu'une autre question s'impose.
Pas :
Le système tient-il ?
Mais :
Que ferions-nous s'il fallait l'abandonner ?
Voilà le test de sortie.
La Suisse pose la bonne question
L'Administration fédérale suisse offre, en ce moment, un cas d'école.
Sa preuve de concept BOSS examine des logiciels libres pour la bureautique, dans un effort plus large de souveraineté numérique. Ce n'est pas un procès d'intention contre le logiciel commercial. On y étudie une bureautique de secours, le traitement d'informations sensibles, et la possibilité de tenir une voie parallèle à l'environnement actuel.
La nuance change tout.
Microsoft 365 n'a pas à être médiocre pour que s'appuyer sur Microsoft 365 devienne un enjeu stratégique.
C'est souvent l'inverse.
Plus un système est bon, plus on s'y installe sans y penser.
Le confort attire les usages.
Les usages appellent les branchements.
Les branchements engendrent des procédures.
Les procédures forment des métiers.
Les métiers deviennent des habitudes de maison.
Et les habitudes, peu à peu, passent pour des évidences.
La dépendance n'arrive donc presque jamais comme une faute.
Elle s'empile à travers des milliers de choix, chacun raisonnable.
C'est pourquoi on ne mesure pas la souveraineté au seul marché public.
La vraie question surgit des années plus tard.
Peut-on encore s'en aller ?
Les données ne font pas la sortie
La version la plus mince du test de sortie porte sur les données.
Peut-on tout emporter ?
Documents.
Courriels.
Bases.
Pistes d'audit.
Configuration.
Métadonnées.
Identités.
Journaux.
Artefacts de modèles.
Réservoirs de savoir.
Il le faut.
Ce n'est pourtant qu'un premier pas.
Supposez qu'une organisation extraie vingt ans de documents d'une plateforme.
Parfait.
Et après ?
Une autre plateforme lit-elle les droits ?
Reconstitue-t-elle les processus ?
Les liens entre documents tiennent-ils ?
Les macros s'exécutent-elles encore ?
Les gabarits restent-ils utilisables ?
Les règles de conservation survivent-elles ?
Peut-on encore inspecter les historiques de contrôle ?
Les automatismes continuent-ils ?
L'authentification se reconstruit-elle ?
Qu'advient-il des applications calées sur des API propriétaires ?
Les agents retrouvent-ils encore quoi que ce soit ?
Les données ont pu quitter les lieux.
L'organisation, elle, est restée.
C'est tout l'écart entre emporter et remplacer.
L'Europe commence à le voir.
Le EU Data Act, applicable depuis septembre 2025, vise à faciliter le changement de prestataire de traitement et de cloud. Les clients sont censés pouvoir migrer, ou faire tourner plusieurs fournisseurs de front.
La règle est utile.
Elle peut ouvrir un droit de partir.
Elle ne fabrique pas, à elle seule, le métier de l'exercer.
Les six épreuves de la sortie
Pour juger une dépendance, mieux vaut la découper.
1. Sortir les données
Peut-on récupérer ce qu'il faut pour continuer ?
Pas seulement des fichiers.
Les relations.
Les métadonnées.
La configuration.
L'historique.
Le contexte.
La piste d'audit.
Une copie brute que personne ne sait reconstruire est, sur le papier, une exportation. Dans la vie, c'est un échec.
2. Sortir techniquement
Une autre technique peut-elle vraiment faire le travail ?
Une option théorique ne suffit pas.
L'usage tourne-t-il là-bas ?
Les interfaces se parlent-elles ?
L'identité migre-t-elle ?
La sécurité tient-elle encore ?
Les performances restent-elles acceptables ?
La maison peut-elle réellement déployer ?
3. Sortir en continuant d'opérer
Les processus essentiels tiennent-ils pendant le passage ?
Les systèmes vivent rarement seuls.
Les finances s'adressent à l'identité.
L'identité s'adresse aux RH.
Les documents nourrissent les processus.
Les processus déclenchent des visas.
Les visas déclenchent des paiements.
La supervision s'appuie sur les journaux.
Les rapports s'appuient sur tout le reste.
Remplacer un outil, c'est souvent découvrir à quelle profondeur il s'était logé dans l'organisme.
4. Sortir avec les compétences
Sait-on encore piloter l'autre voie ?
C'est l'une des dépendances les plus sous-estimées.
Une infrastructure peut rester remplaçable sur le plan technique et devenir irremplaçable dans l'institution.
Le savoir s'évapore.
Les administrateurs se spécialisent.
Les procédures se fanent.
La documentation passe au rang d'archive.
L'alternative reste sur un schéma.
Personne ne l'a touchée depuis cinq ans.
Ce n'est pas de la redondance.
C'est de l'archéologie.
5. Sortir à temps
Combien de temps faudrait-il pour partir ?
C'est peut-être l'épreuve la plus cruelle.
On peut avoir les données, la technique et le savoir-faire.
Mais si le basculement demande dix-huit mois et que la dépendance s'éteint en quatorze jours, le reste n'est que discussion de salon.
La sortie a donc une durée.
Une voie qu'on ne peut pas ouvrir dans le délai disponible n'est pas une voie opérationnelle.
6. Pouvoir décider de sortir
Qui, concrètement, peut trancher ?
Les équipes techniques construisent parfois des issues que l'institution n'a pas le mandat d'ouvrir.
Les contrats s'en mêlent.
Les régulateurs s'en mêlent.
Les calendriers budgétaires s'en mêlent.
Les règles d'achat s'en mêlent.
Les instances de gouvernance s'en mêlent.
La responsabilité politique s'en mêle.
Les ingénieurs peuvent connaître le chemin par cœur.
Cela n'autorise pas la maison à l'emprunter.
La souveraineté demande donc plus qu'une option technique.
Elle demande une capacité de décision.
L'Europe mesure désormais plus loin que le disque
Cette lecture plus large de la dépendance gagne la politique européenne.
Le Cloud and AI Development Act proposé par la Commission européenne esquisse un cadre de souveraineté à plusieurs étages.
Au plus simple, il s'agit de traiter et de stocker les données dans l'Union européenne.
Le cadre ne s'arrête pas au territoire.
Plus haut, on interroge l'indépendance vis-à-vis des pays tiers, la transparence des chaînes logicielles, la propriété, le contrôle.
Le déplacement d'idée est réel.
Pendant des années, le « cloud souverain » se réduisait souvent à une carte.
Où est le centre de données ?
Où sont les disques ?
Où sont les copies de sauvegarde ?
Le lieu compte.
Mais le lieu, à lui seul, dit fort peu du contrôle.
Un serveur peut se tenir en Europe et dépendre d'un logiciel conçu ailleurs.
Une filiale européenne peut faire tourner une infrastructure que la société mère, sous une autre juridiction, tient réellement.
Un cloud local peut s'appuyer sur des identités étrangères, des processeurs, des microgiciels, des dépôts, des consoles d'administration ou des outils de sécurité.
Un service d'IA européen peut, au bout du compte, reposer sur des modèles, des accélérateurs, des bibliothèques et des plateformes tenus hors d'Europe.
L'adresse physique répond à une question.
La souveraineté en pose bien d'autres.
Ce qui tient sous la promesse
L'intelligence artificielle le rend presque trop visible.
L'Europe veut davantage d'IA souveraine.
La Suisse aussi.
En juillet 2026, ETH Zurich a présenté Apertus 1.5 comme un pas de plus vers une infrastructure d'IA souveraine sur la durée — une voie ouverte face aux modèles commerciaux propriétaires, pour la recherche, l'enseignement, l'administration et l'industrie.
L'intérêt stratégique est réel.
Un modèle entièrement ouvert n'efface pourtant pas la dépendance.
Le modèle a besoin de calcul.
Le calcul a besoin d'accélérateurs.
Les accélérateurs ont besoin de microgiciels.
Les grappes ont besoin de réseaux.
Les réseaux ont besoin d'équipements.
Les équipements ont besoin de chaînes d'approvisionnement.
L'entraînement a besoin de cadres logiciels.
Les cadres ont besoin de bibliothèques.
Les bibliothèques ont besoin de dépôts.
L'exploitation a besoin d'identité, de supervision, de stockage et de sécurité.
Tout a besoin d'électricité.
Et, au bout, quelqu'un doit comprendre comment l'ensemble tient.
On n'achète donc pas la souveraineté comme un article.
Il n'existe pas de bouton « modèle souverain ».
Pas de référence catalogue « cloud souverain ».
Pas de système d'exploitation qui, par magie, rendrait souveraine l'organisation qui l'installe.
Chaque couche peut améliorer la situation.
Aucune n'est le système.
La question qui sert encore :
Si cette pièce disparaissait demain, que ne pourrions-nous plus faire ?
Dépendre n'est pas échouer
Ici, la mauvaise conclusion est à portée de main.
Si dépendre crée un risque, l'indépendance serait la réponse.
Tout construire chez soi.
Tout héberger chez soi.
Ne retenir que des fournisseurs nationaux.
Écarter la technique étrangère.
Écarter les plateformes.
Écarter les services extérieurs.
Ce n'est pas de la souveraineté.
C'est le plus souvent de l'inefficacité en costume de principe.
Les économies modernes sont des réseaux de dépendances.
Les entreprises aussi.
Les États aussi.
La Suisse ne fabrique pas chaque semi-conducteur qu'elle emploie.
L'Europe ne tient pas chaque bibliothèque qui tourne dans ses infrastructures.
Les États-Unis s'appuient sur une fabrication étrangère.
La Chine s'appuie sur des techniques et des marchés hors de ses frontières.
Personne de sérieux n'est autarcique.
Et personne ne devrait viser cela.
La question n'est pas de savoir si l'on dépend.
Elle est de savoir si la dépendance reste maîtrisable.
La voit-on ?
L'évalue-t-on ?
Peut-on desserrer la concentration ?
Peut-on garder le métier ?
Peut-on ouvrir une autre voie là où les conséquences le justifient ?
Et peut-on partir lorsque le décor change ?
C'est cela, la souveraineté.
Le confort consomme la latitude
Le dur, c'est que la latitude a un prix.
Deux systèmes coûtent plus cher qu'un.
Plusieurs fournisseurs alourdissent l'achat.
Une architecture portable impose des compromis.
Les normes ouvertes n'offrent pas chaque fonction propriétaire.
Former les gens à une autre voie prend du temps.
Tenir une capacité qu'on n'utilise pas a l'air d'un gaspillage.
Les exercices de sortie interrompent le travail utile.
La redondance paraît superflue tant que rien ne casse.
L'optimisation pousse donc, naturellement, à l'opposé.
Un fournisseur.
Une plateforme.
Un système d'identité.
Une architecture de préférence.
Un modèle d'exploitation.
Tout uniformiser.
Couper les doublons.
Gagner en rendement.
Et chaque décision, prise seule, est saine.
Jusqu'au jour où les conditions basculent.
C'est ainsi que l'on perd d'ordinaire la souveraineté.
Pas en capitulant.
En optimisant.
La maison troque, peu à peu, sa latitude contre le confort. Comme chaque échange, isolément, paraît raisonnable, personne ne voit combien de liberté a disparu au total.
Une clause n'est pas une capacité
Les contrats d'entreprise sérieux prévoient déjà la fin.
Il y a des clauses.
Des préavis.
Des devoirs de restitution.
Une aide au passage.
Des certificats d'effacement.
Des dispositions de continuité.
Les juristes peuvent les relire.
Les achats peuvent les viser.
Les conseils peuvent s'en rassurer.
Nous avons une stratégie de sortie.
Peut-être.
Mais partir sur le papier et partir dans la vie sont deux métiers.
Le fournisseur peut honorer chaque obligation. Le client peut rester coincé.
Les fichiers arrivent exactement comme promis.
La maison ne sait pas reconstruire le système.
La licence s'éteint à l'heure dite.
Le remplaçant a six mois de retard.
Le fournisseur accompagne la transition.
Personne, à l'intérieur, ne connaît assez l'architecture héritée pour diriger cet accompagnement.
Le contrat a parfaitement tenu.
La sortie a échoué.
La capacité de partir ne peut donc pas rester un document.
Elle doit devenir un métier.
On répète la sortie, ou on l'imagine
Ailleurs, les organisations le savent déjà.
On ne déclare pas une sauvegarde fiable parce que la tâche affiche SUCCESS.
On la restaure.
On ne déclare pas un plan de reprise crédible parce qu'un second environnement existe.
On teste le basculement.
On ne suppose pas qu'une procédure d'urgence tient parce qu'elle est rédigée.
On la joue.
Les stratégies de sortie méritent la même discipline.
Déplacer un usage réel.
Restaurer de vraies données ailleurs.
Faire tourner un autre système d'identité.
Reconstruire une application à partir de dépendances écrites.
Mesurer le temps.
Noter ce qui casse.
Découvrir quel savoir n'existe que dans des têtes.
Retrouver le contrat oublié.
Identifier le format propriétaire que l'on croyait ouvert.
Voir quelle alternative, convaincante dans PowerPoint, s'effondre sous une charge réelle.
Puis réparer.
Une sortie répétée coûte.
Une sortie jamais jouée n'existe pas.
Le paradoxe de l'alternative qui dort
Autre piège.
Les alternatives se fanent si on ne s'en sert pas.
Cela arrive partout.
Un second fournisseur existe, mais ne reçoit presque plus de commandes.
Un environnement de reprise existe, mais tourne sur d'anciennes configurations.
Un logiciel libre est installé, mais personne ne s'en sert.
Une procédure manuelle survit dans un classeur, mais plus aucun agent ne l'a exécutée depuis des années.
Un second compte cloud existe, mais toute l'automatisation vise le premier.
Sur le papier, la redondance tient.
Dans l'exploitation, elle s'évapore.
D'où une exigence étrange.
Si une voie de repli mérite d'être gardée, il faut s'en servir de temps à autre.
Non parce qu'elle est meilleure.
Parce qu'un métier s'entretient.
C'est précisément ce qui rend l'expérience BOSS de la Suisse plus intéressante qu'un débat d'achat.
La question n'est pas de savoir si une bureautique libre doit, demain, chasser Microsoft 365.
Elle est de savoir si la Suisse conserve assez de savoir, d'infrastructure et de pratique pour avoir encore un choix si le décor change.
C'est un objectif autrement adulte.
Quand la géopolitique entre dans l'architecture
Longtemps, l'achat technologique a été traité, surtout, comme un dossier commercial.
Le prix.
Les performances.
Les fonctions.
La sécurité.
Le support.
L'intégration.
Cela reste nécessaire.
Mais la technique se tient désormais tout près du pouvoir géopolitique.
On peut restreindre les semi-conducteurs.
Les services cloud relèvent d'une juridiction.
La distribution de logiciels peut être interrompue.
Les chaînes d'approvisionnement peuvent servir d'instrument politique.
Une acquisition peut changer le propriétaire.
Un gouvernement peut sanctionner.
Les contrôles à l'exportation peuvent redéfinir ce que l'on vend, à qui, et sous quelles conditions.
La chance qu'une dépendance précise s'éteigne demain peut rester faible.
La conséquence, elle, peut être immense.
Cela change la question d'architecture.
Dès qu'un système critique s'appuie sur des techniques hors de portée, le risque géopolitique devient une propriété technique du système.
Non que les fournisseurs étrangers soient, par nature, peu fiables.
Parce qu'un contrôle extérieur existe.
Une dépendance peut rester tout à fait rationnelle — et exiger, malgré tout, un chemin de sortie.
La revue d'architecture qui manque
Peut-être faut-il donc, dans les revues d'architecture, une question de plus.
On dépense une énergie considérable à demander si un système proposé tiendra la charge.
Peut-il absorber dix fois le trafic ?
Survit-il à la panne d'un serveur ?
Se relève-t-il d'une base hors service ?
Reste-t-il sûr ?
Respecte-t-il le SLA ?
Toutes questions saines.
Mais une autre devrait siéger à côté.
Comment cesse-t-on de s'en servir ?
Que faut-il extraire ?
Que faut-il reconstruire ?
Quel savoir doit survivre ?
Quelles normes comptent vraiment ?
Quelles dépendances se tiennent en dessous ?
Combien de temps demanderait le passage ?
Qui a le mandat de le déclencher ?
Que continuerait de tourner pendant la transition ?
Que s'arrêterait ?
Et quand a-t-on, pour la dernière fois, prouvé l'une de ces réponses ?
Soudain, l'architecture de sortie n'est plus une hygiène d'achat.
Elle devient de l'ingénierie de résilience.
Le test de sortie
Prenez n'importe quelle dépendance qui compte.
Votre cloud.
Votre fournisseur d'IA.
Votre plateforme d'identité.
Votre ERP.
Votre réseau de paiement.
Votre fournisseur de puces.
Votre infrastructure de communications.
Votre dépôt de code.
Votre suite bureautique.
Votre prestataire logistique.
Votre source d'énergie.
Puis imaginez que, demain, la relation change.
Le fournisseur tombe.
Le produit est retiré.
Les prix deviennent inacceptables.
Une acquisition déplace le risque.
La règle change.
Les rapports géopolitiques se dégradent.
Ou la technique cesse simplement d'être le bon choix.
Posez alors six questions.
Peut-on récupérer ce qui compte ?
Autre chose peut-il remplir la fonction ?
Peut-on opérer pendant le passage ?
Le métier est-il encore là ?
Peut-on bouger à temps ?
A-t-on le mandat d'agir ?
Si les six réponses sont oui, la dépendance peut être profonde.
Elle reste maîtrisable.
Si plusieurs réponses sont non, la maison peut encore détenir les contrats, les serveurs et les données.
Elle peut encore être extraordinairement efficace.
Elle peut encore avoir d'excellents fournisseurs.
Elle peut encore se croire aux commandes.
Mais elle a cédé quelque chose d'essentiel.
La faculté de choisir autrement.
La souveraineté commence où le confort s'arrête
Rien n'interdit de prendre la meilleure technique disponible.
Rien n'est souverain, par nature, dans une technique nationale inférieure.
Rien n'est noble à reconstruire une infrastructure banale sous prétexte que d'autres l'ont faite les premiers.
La souveraineté n'exige pas d'éviter la dépendance.
Elle exige de comprendre ce que la dépendance coûte, au-delà de l'argent.
Chaque confort crée un allant de soi.
Chaque allant de soi peut devenir une dépendance.
Chaque dépendance cède un peu de contrôle.
La plupart de ces cessions sont parfaitement acceptables.
Certaines sont extrêmement utiles.
L'erreur est de les laisser devenir invisibles.
Une organisation souveraine peut s'appuyer sur des clouds américains, une infrastructure européenne, du matériel chinois, des logiciels suisses et des bibliothèques libres écrites par des gens qu'elle n'a jamais rencontrés.
L'origine n'est pas la question qui tranche.
Celle qui tranche : reste-t-il assez d'autres voies, de métier et d'autorité pour changer de cap.
C'est plus dur que l'achat.
Plus dur que la localisation.
Plus dur que la réglementation.
Plus dur que de rédiger une clause.
Parce que la vraie latitude s'entretient pendant que tout marche.
Et pendant que tout marche, il y a toujours plus urgent.
C'est précisément pour cela que cela compte.
On découvre trop souvent les dépendances lorsqu'elles cassent.
Il faudrait les découvrir pendant qu'elles tiennent.
L'épreuve décisive d'une dépendance n'est pas de savoir si elle marche tant que la relation est bonne.
C'est de savoir si l'on tient encore lorsque la relation s'arrête.
On n'est pas souverain parce qu'on détient le contrat.
On l'est lorsqu'on peut encore partir.