Commande publique IT : trois chemins vers la souveraineté, tous ne mènent pas au même endroit

# Commande publique IT : trois chemins vers la souveraineté, tous ne mènent pas au même endroit

L'État commence enfin à mettre son budget là où sont ses discours. En 2026, la pression réglementaire et les directives de la DINUM poussent clairement les acheteurs publics à préférer des solutions issues de la filière française et européenne. Pour un DSI ou un CTO de PME ou d'ETI qui travaille avec le secteur public — ou qui cherche simplement à sortir de sa dépendance aux acteurs américains —, c'est un signal fort. Mais un signal ne suffit pas à construire une architecture. Il faut choisir un chemin.

Il y en a essentiellement trois. Et ils ne se valent pas, ni techniquement, ni sur le plan de la souveraineté réelle. Je vais les poser ici franchement, sans langue de bois.

Le contexte : ce que « filière française » veut dire concrètement en 2026

Avant de comparer les approches, posons un cadre. Quand l'État parle d'orientation vers la filière française, il parle de plusieurs choses à la fois : hébergement sur sol européen, code source auditable, absence de transferts de données vers des juridictions tierces, et chaîne de sous-traitance maîtrisée. Ce n'est pas juste un label. C'est une exigence systémique.

Le problème, c'est que beaucoup d'entreprises interprètent ce signal comme une opportunité commerciale à saisir rapidement — en habillant leur offre existante d'un vernis souverain. Et certaines le font sincèrement mais insuffisamment. Il faut donc distinguer ce qui tient la route techniquement de ce qui ne tient pas à l'examen.

Approche 1 : Le SaaS souverain certifié — la voie balisée

Architecture

Cette approche repose sur des solutions logicielles déjà packagées, hébergées en France ou en Europe, qualifiées SecNumCloud ou en cours de qualification. L'éditeur gère l'infrastructure, les mises à jour, la sécurité. Le client achète un service, pas une brique.

C'est la voie la plus directe pour une PME qui n'a pas d'équipe infra dédiée. Des acteurs comme Tixeo — pour la visioconférence sécurisée — ou Oodrive — pour la gestion documentaire sensible — illustrent ce modèle. Ils ont construit leur offre sur la conformité comme argument différenciant, pas comme option.

Intégration

C'est là que ça se complique. Le SaaS souverain certifié présente souvent une surface d'intégration plus étroite que les offres dominantes américaines. Les connecteurs natifs vers d'autres outils du marché sont moins nombreux, les API parfois moins matures. Ce n'est pas une critique — c'est un état de fait lié à la taille de l'écosystème. Pour un SI qui s'appuie fortement sur des automatisations ou des interconnexions complexes, il faut anticiper un travail d'adaptation.

Gouvernance

L'avantage ici est réel : le contrat est soumis au droit français, les données ne quittent pas le territoire européen, et l'éditeur est auditable. En cas de litige ou de demande d'accès par une autorité étrangère — le cas de figure que le Cloud Act américain rend théoriquement possible avec n'importe quel acteur soumis à la juridiction américaine —, la position du client est protégée.

Verrouillage résiduel

Le risque de lock-in existe quand même. Un SaaS souverain sans export de données facilité, sans format ouvert, sans clause de réversibilité claire dans le contrat, c'est une dépendance qui change de visage mais ne disparaît pas. Il faut lire les contrats. Vraiment les lire.

Approche 2 : L'open source auto-hébergé — la voie exigeante

Architecture

Ici, on parle de déployer soi-même des solutions open source — que ce soit pour la collaboration, la gestion de projet, la messagerie ou d'autres briques fonctionnelles — sur une infrastructure dont on maîtrise la localisation. L'hébergement peut être géré en interne ou confié à un hébergeur européen de confiance.

Cette approche suppose une équipe technique capable de gérer des déploiements, des mises à jour, et potentiellement des incidents. Ce n'est pas la voie de la facilité. Mais c'est celle de la maîtrise réelle.

Intégration

L'open source bien choisi offre souvent une excellente interopérabilité, précisément parce que les formats ouverts sont une philosophie, pas une case à cocher. Les échanges avec d'autres systèmes sont documentés, les formats exportables, les données accessibles. C'est là un avantage structurel que les offres fermées — américaines ou européennes — ne peuvent pas répliquer par définition.

Gouvernance

La gouvernance est maximale sur le papier : vous contrôlez le code, l'infrastructure, les données. Mais la gouvernance réelle dépend de vos capacités opérationnelles. Un déploiement open source mal maintenu, c'est une surface d'attaque qui grandit. La souveraineté technique sans la sécurité opérationnelle, c'est une illusion.

Il faut aussi regarder qui gouverne le projet open source lui-même. Une fondation européenne, une communauté internationale neutre, ou un projet sponsorisé majoritairement par un acteur américain dont les intérêts peuvent diverger des vôtres à terme ? Ce n'est pas une question rhétorique.

Verrouillage résiduel

C'est l'approche qui desserre le plus les verrous contractuels et techniques. Pas de clause d'exclusivité, pas de format propriétaire, pas de dépendance à une roadmap décidée ailleurs. Mais le coût de sortie n'est pas nul : il est en compétences internes, en temps de formation, en charge opérationnelle.

Approche 3 : Le partenariat avec un intégrateur souverain — la voie pragmatique

Architecture

Cette troisième voie consiste à s'appuyer sur un intégrateur ou un ESN français qui assemble des briques — open source, éditeurs européens, parfois des composants du marché — et prend en charge la cohérence de l'ensemble. L'entreprise cliente achète un service managé souverain, sans gérer elle-même la complexité d'un déploiement auto-hébergé.

Des acteurs comme Alter Way ou Dawex — pour prendre deux exemples aux positionnements bien distincts — illustrent cette catégorie d'intermédiaires qui jouent la carte de l'assemblage souverain plutôt que de l'édition pure.

Intégration

L'intégration est ici la force de ce modèle. L'intégrateur connaît les contraintes de son client, les systèmes existants, les usages. Il peut faire les ajustements que ni le SaaS packagé ni l'open source brut ne permettent facilement. La surface d'intégration est sur-mesure.

Gouvernance

La question clé est : qui dépend de qui ? Si l'intégrateur s'appuie lui-même sur des sous-couches américaines — hébergement, outils de monitoring, services tiers — la souveraineté de l'ensemble est aussi solide que son maillon le plus faible. Il faut exiger la cartographie complète de la chaîne de valeur, pas juste la déclaration d'intention.

C'est un travail de due diligence que beaucoup de DSI ne font pas assez tôt dans le cycle d'achat. Je pense que c'est l'erreur la plus fréquente dans ce type de démarche.

Verrouillage résiduel

Le risque est celui de la dépendance à l'intégrateur lui-même. Si les configurations, les scripts, les automatisations sont mal documentés et non portables, changer de prestataire devient aussi douloureux que de quitter un acteur américain. La réversibilité doit être contractualisée dès le départ, avec des livrables de documentation exigibles.

Tableau de synthèse

| Critère | SaaS souverain certifié | Open source auto-hébergé | Intégrateur souverain |

|---|---|---|---|

| Maîtrise de l'architecture | Faible (déléguée à l'éditeur) | Maximale | Moyenne (dépend du contrat) |

| Facilité d'intégration | Limitée | Bonne si formats ouverts | Haute (sur-mesure) |

| Gouvernance contractuelle | Forte si bien qualifié | Totale si hébergement maîtrisé | Variable selon la chaîne |

| Risque de lock-in résiduel | Moyen (format, réversibilité) | Faible (compétences internes) | Élevé si mal contractualisé |

| Charge opérationnelle interne | Faible | Élevée | Moyenne |

Ce que je retiens — et ce qu'il faut exiger

L'orientation de la commande publique vers la filière française est une bonne nouvelle structurelle. Mais elle ne doit pas devenir une prime aux belles brochures. Il faut des critères techniques réels dans les appels d'offres : localisation des données vérifiable, format d'export documenté, clause de réversibilité chiffrée, cartographie des sous-traitants.

Et pour les DSI et CTO du privé qui suivent ce mouvement avec intérêt — parce que leurs clients publics leur demandent de s'aligner, ou parce qu'ils veulent anticiper des exigences réglementaires à venir —, le message est le même : la souveraineté numérique n'est pas un label à apposer sur une offre existante. C'est une architecture de décision qui commence par les contrats, se construit dans les choix techniques, et se mesure dans la capacité réelle à partir sans tout perdre.

Il faut se poser une question simple face à chaque solution présentée comme « souveraine » : si je veux partir dans dix-huit mois, qu'est-ce que je peux emporter ? Si la réponse est floue, la souveraineté est un argument marketing, pas une réalité opérationnelle.