Les 8 critères de souveraineté numérique à intégrer dans un appel d'offres informatique

Un critère de souveraineté n'a d'effet que s'il est décomposé en exigences vérifiables et pondéré à un niveau qui peut faire basculer une décision. Les huit dimensions à couvrir reprennent les huit objectifs du Cloud Sovereignty Framework de la Commission européenne : souveraineté stratégique, juridique, des données et de l'IA, opérationnelle, chaîne d'approvisionnement, ouverture technologique, sécurité et conformité, impact environnemental. Chacune se traduit par une question posée au fournisseur et une preuve exigée en réponse.

En France, 91 % des décideurs interrogés considèrent désormais la souveraineté numérique comme un enjeu stratégique majeur, d'après l'enquête menée par Infopro Digital Études pour L'Argus de l'assurance et Efficy auprès de 412 répondants en mars et avril 2026.

Julian Maurel, PDG de Jahia, observe pourtant dans une tribune publiée par IT for Business le 30 juin 2026 que ce critère reste "cantonné à un critère pondéré autour de 10 %, quand le prix en pèse 50 ou 60 %". C'est une observation de terrain, pas une statistique d'enquête, et nous la donnons comme telle.

Un critère présent partout, qui ne déplace presque jamais un classement. Voici comment lui donner un effet, en s'appuyant sur le référentiel que la Commission européenne applique désormais à ses propres marchés.

L'essentiel

• La question décisive n'est pas d'inscrire la souveraineté dans la consultation, mais de choisir entre une pondération, une condition d'admissibilité et une clause contractuelle. Les trois ne produisent pas le même résultat.
• Le précédent qui change la conversation : pour son propre marché de cloud souverain de 180 millions d'euros, la Commission européenne a fait du niveau de souveraineté une condition d'admissibilité, et non un critère pondéré.
• Une pondération n'a d'effet qu'au-dessus de l'écart de prix habituel entre deux offres comparables. À 10 % face à un prix qui pèse 60 %, elle ne déplace aucun classement.
• Chaque critère se juge sur une preuve exigible, pas sur une déclaration. Un critère écrit sans preuve attendue est invérifiable en cas de contentieux.
• La réversibilité est le test le plus révélateur : un fournisseur incapable de chiffrer une sortie a déjà répondu à la question de la dépendance.
• Construisez la grille avant de regarder le marché, faites-la valider par les métiers, et placez la notoriété du fournisseur tout en bas.

Pourquoi intégrer des critères de souveraineté numérique dans un appel d'offres ?

Parce qu'une dépendance non évaluée à l'achat devient un coût subi pendant toute la durée du contrat. Un contrat de plateforme d'expérience numérique engage une organisation sur plusieurs années, pendant lesquelles le cadre juridique, la structure capitalistique du fournisseur et les conditions tarifaires peuvent tous changer sans son accord.

Le cadre s'est précisé, et il est désormais citable.

En France, la DINUM a publié le 6 février 2026 la doctrine de l'État en matière d'achats publics numériques, en coordination avec les ministères de l'Économie, de l'Intelligence artificielle et de la Fonction publique. Elle s'appuie sur une circulaire du Premier ministre et sur l'article 31 de la loi SREN du 21 mai 2024. Deux points en ressortent pour un acheteur : les données d'une sensibilité particulière doivent être hébergées chez un fournisseur cloud qualifié SecNumCloud, et l'interopérabilité passe par des interfaces normalisées et des schémas ouverts.

Au Sénat, la commission d'enquête sur les coûts et modalités de la commande publique a déposé le 8 juillet 2025 le rapport "L'urgence d'agir pour éviter la sortie de route : piloter la commande publique au service de la souveraineté économique", n° 830 (2024-2025), rapporteur Dany Wattebled. Il rappelle que dans le secteur public les logiciels libres sont utilisés en priorité, et reproche notamment aux centrales d'achat de fonctionner comme de simples intermédiaires plutôt que comme des prescripteurs porteurs d'exigences.

Enfin, la Direction générale des Entreprises a ouvert du 13 mai au 5 juin 2026 une consultation publique sur les critères de souveraineté numérique, portant sur l'investissement, l'emploi et l'innovation, pour alimenter les travaux franco-allemands lancés au sommet de Berlin de novembre 2025. Autrement dit, la définition même des critères est encore en mouvement : ce que vous écrivez aujourd'hui devra pouvoir être révisé.

Deux forces s'opposent à cette intention, et les ignorer explique la plupart des critères décoratifs.

La première est le risque personnel du décideur. On demande à un acheteur de s'engager pour trois, cinq ou huit ans, et la personne qui signe porte ce choix. L'adage du secteur résume la mécanique : personne n'a jamais été licencié pour avoir acheté IBM. Si à l'inverse la décision a été prise au nom de la souveraineté au détriment de tout le reste, elle produit un rejet de la souveraineté elle-même.

La seconde se joue avant la consultation, dans l'expression du besoin. Quand une organisation cherche une alternative à un logiciel dominant et décrit son besoin en listant les fonctionnalités de ce logiciel, la consultation est déjà orientée vers lui. Repartir du besoin réel des utilisateurs, et non du produit installé, est la condition pour que les critères de souveraineté servent à quelque chose.

Qu'est-ce qu'une solution réellement souveraine ?

Une solution souveraine est une solution dont l'acheteur peut à tout moment déterminer qui a accès à ses données, sous quelle loi, et à quelles conditions il peut partir. La nationalité de l'éditeur ne suffit pas à l'établir. Une entreprise européenne peut héberger chez un fournisseur soumis à une législation extraterritoriale, dépendre d'un actionnaire non européen ou sous-traiter son support hors de l'Union.

L'inverse est vrai aussi. Un hébergement en France ne protège pas d'une injonction visant la maison mère d'un éditeur, dès lors que celle-ci relève d'un droit qui l'autorise. C'est pourquoi les référentiels récents évaluent une chaîne de dépendances plutôt qu'un pays d'hébergement.

Le référentiel de référence : le Cloud Sovereignty Framework de la Commission européenne

Les huit critères détaillés plus bas ne sont pas une invention maison. Ils reprennent la structure du Cloud Sovereignty Framework publié par la Commission européenne en octobre 2025, dans sa version 1.2.1. C'est le point que la plupart des articles sur le sujet omettent, et c'est celui qui donne à une grille d'évaluation son autorité devant un comité d'achat.

Le framework définit huit objectifs de souveraineté : stratégique, juridique, opérationnel, environnemental, transparence de la chaîne d'approvisionnement, ouverture technologique, sécurité, et conformité au droit de l'Union. Il y ajoute une échelle de notation, les Sovereignty Effectiveness Assurance Levels, ou SEAL, graduée de SEAL-0, qui décrit une absence complète de souveraineté, à SEAL-4, qui suppose une chaîne d'approvisionnement européenne de bout en bout, des composants électroniques au logiciel.

Ce n'est pas un document théorique. La Commission l'a appliqué à son propre achat. Pour son marché de cloud souverain de 180 millions d'euros sur six ans, attribué le 17 avril 2026, elle écrit noir sur blanc que "pour être éligibles, les fournisseurs devaient atteindre le niveau SEAL-2". Le niveau de souveraineté était donc une condition d'admissibilité, et non un critère pondéré. Les quatre marchés ont été attribués à des fournisseurs européens.

Pour un acheteur, ce précédent vaut argument. Quand la Commission européenne elle-même transforme un niveau de souveraineté en condition d'admissibilité pour un marché de 180 millions d'euros, la question de savoir si l'on a le droit de le faire cesse d'être théorique.

Les 8 critères de souveraineté numérique à évaluer

1. Évaluer la souveraineté stratégique

La souveraineté stratégique mesure votre capacité à peser sur l'avenir du produit. Elle se vérifie en demandant si la roadmap est contractualisable, si des engagements de maintien de fonctionnalités peuvent être inscrits au marché, et quel est le préavis en cas d'arrêt d'une brique.

Un éditeur qui refuse tout engagement écrit sur la trajectoire produit vous demande d'accepter un risque que vous ne pouvez pas provisionner. Demandez le processus d'évolution du produit, le rôle des clients dans les arbitrages, et la politique de fin de vie des versions.

2. Vérifier la souveraineté juridique

La souveraineté juridique porte sur la loi applicable et sur l'exposition aux législations extraterritoriales. Elle se vérifie par trois éléments : la structure capitalistique de l'éditeur et de ses hébergeurs, le droit applicable au contrat et la juridiction compétente, et l'existence d'un mécanisme de réponse aux demandes d'autorités étrangères.

La question à poser est précise : quelle entité juridique signe le contrat, quelle est sa chaîne de contrôle capitalistique, et cette chaîne comporte-t-elle une entité soumise à une législation extraterritoriale. Une réponse évasive sur ce point est une réponse.

3. Garantir la souveraineté des données et de l'IA

La souveraineté des données couvre leur localisation, leur chiffrement, la détention des clés et l'usage qui en est fait pour l'entraînement de modèles. Le RGPD fournit déjà l'ossature documentaire pour les organisations qui y sont soumises : registre des traitements, analyse d'impact, et engagements de sous-traitance au sens de l'article 28 du règlement (UE) 2016/679. Les organisations suisses demandent les mêmes pièces sur le fondement de leur propre loi fédérale.

L'IA ajoute une question que beaucoup de consultations oublient encore. Demandez explicitement où sont traités les contenus soumis à un modèle, si les données du client peuvent servir à l'entraînement, si le modèle peut être hébergé dans votre environnement, et si vous pouvez choisir ou remplacer le modèle utilisé. Un service qui ne sait pas répondre transfère vos contenus dans une chaîne que vous ne maîtrisez pas.

4. Maîtriser la souveraineté opérationnelle

La souveraineté opérationnelle désigne votre capacité à exploiter la solution sans dépendre exclusivement de l'éditeur. Elle se mesure à la localisation des équipes de support et d'infogérance, aux droits d'accès administrateur réellement accordés, et à l'autonomie des équipes internes sur les tâches courantes.

Un point mérite une attention particulière : la capacité des équipes métier à produire et modifier sans passer par un développement. Une plateforme qui impose un ticket pour chaque changement de page crée une dépendance opérationnelle qui n'apparaît dans aucune grille technique, mais qui se paie tous les mois.

5. Examiner la chaîne d'approvisionnement

La transparence de la chaîne d'approvisionnement logicielle est le critère le plus souvent négligé et l'un des plus déterminants. C'est aussi l'un des huit objectifs du framework européen. Une solution présentée comme souveraine dont l'essentiel des composants provient de briques tierces non maîtrisées ne l'est qu'en façade.

Demandez la nomenclature des composants, ou SBOM, la politique de mise à jour des dépendances, le délai de correction des vulnérabilités critiques, et la liste des sous-traitants ayant accès à l'environnement ou aux données. Ces éléments sont documentables, et leur absence est en soi une information.

6. Favoriser la souveraineté technologique

L'ouverture technologique est votre liberté de choisir et de changer votre socle technique. Elle repose sur trois éléments vérifiables : la nature ouverte ou fermée du code, l'existence d'API documentées permettant l'export des contenus et des structures, et l'absence de format propriétaire non documenté. C'est le sens de la priorité donnée aux logiciels libres que rappelle le rapport sénatorial cité plus haut.

L'open source facilite l'audit et réduit la dépendance, sans la supprimer. La question utile n'est pas de savoir si la solution est open source, mais si vous pourriez, techniquement et juridiquement, reprendre la main sur votre plateforme si votre fournisseur disparaissait.

7. Renforcer la sécurité et la conformité

Dans les secteurs les plus régulés, l'assurance en tête, la sécurité et la conformité constituent le critère le plus facile à objectiver, parce qu'il repose sur des certifications vérifiables. Selon la sensibilité des données traitées, un acheteur peut exiger ou pondérer des qualifications reconnues, en les nommant dès le règlement de la consultation. SecNumCloud, délivrée par l'ANSSI, en est l'exemple français : elle n'est pas une obligation générale, mais la doctrine de l'État la rend nécessaire pour les données d'une sensibilité particulière.

Exigez les attestations en cours de validité, avec leur périmètre exact et leur organisme certificateur, plutôt qu'une mention de conformité en réponse. Une certification qui ne couvre pas l'environnement qui vous sera livré ne vous protège pas.

8. Intégrer les critères environnementaux

L'impact environnemental est le huitième objectif du framework européen, et il se rattache à la souveraineté par la localisation des infrastructures. Demandez le PUE des centres de données concernés, le mix énergétique du site d'hébergement, et la politique de durée de vie du matériel.

Ces indicateurs sont publiés par la plupart des hébergeurs européens. Leur absence de la réponse mérite d'être notée au même titre qu'une absence de certification.

Pondération, condition d'admissibilité ou clause contractuelle

Vous connaissez maintenant les huit critères. Reste à décider comment les employer, car un même critère ne produit pas le même effet selon la place que vous lui donnez. Il faut donc trancher une question avant d'écrire la grille : la souveraineté sera-t-elle un facteur de pondération, une condition d'admissibilité qui écarte une candidature, ou un engagement contractuel assorti de pénalités. Les trois options sont légitimes, elles ne produisent pas le même résultat, et les confondre est la première cause de critères décoratifs.

En pondération, la souveraineté entre dans la note aux côtés du prix et des fonctionnalités. C'est l'option la plus fréquente chez les acheteurs publics de l'Union, tenus par l'article 67 de la directive 2014/24/UE de retenir des critères liés à l'objet du marché et proportionnés. Elle n'a d'effet réel qu'à condition d'être pondérée au-dessus de l'écart de prix habituel entre deux offres comparables. À 10 % face à un prix pesant 60 %, elle ne déplacera aucun classement.

En condition d'admissibilité, la consultation écarte d'emblée les candidats qui ne remplissent pas une exigence posée, par exemple un niveau minimal sur l'échelle SEAL, ou l'hébergement chez un fournisseur qualifié SecNumCloud que la doctrine de l'État impose déjà pour les données d'une sensibilité particulière. L'effet est immédiat et sans ambiguïté. En contrepartie, l'exigence doit être proportionnée au besoin, justifiée par la sensibilité des données, et vérifiable sur pièces. Cette voie suppose aussi qu'un marché de fournisseurs conformes existe réellement, sans quoi la consultation se retrouve sans offre exploitable.

En clause contractuelle, souvent oubliée et cumulable avec les deux autres : encadrer l'accès aux données par le titulaire, assortir cet engagement de pénalités, imposer un plan de réversibilité chiffré. Cette voie produit des effets là où l'exclusion serait disproportionnée ou irréaliste, notamment quand aucune alternative mature n'existe encore sur le segment.

Exemple de grille d'évaluation pour un appel d'offres informatique

Le tableau ci-dessous ne décrit que le bloc souveraineté de la note. Il se combine à vos critères fonctionnels, techniques et de prix : les pourcentages de la troisième colonne se répartissent à l'intérieur de l'enveloppe que vous consacrez à la souveraineté, et la quatrième indique ce que cela représente si vous accordez 30 % de la note globale à ce bloc.

Cette répartition est un point de départ à ajuster selon la sensibilité des données traitées. L'important est que l'enveloppe consacrée à la souveraineté reste supérieure à l'écart de prix habituel entre deux offres comparables, sans quoi le critère ne discriminera jamais. Pour les traitements les plus sensibles, la question à se poser reste celle de la condition d'admissibilité plutôt que de la pondération.

Neutraliser le réflexe de marque avant d'écrire la grille

Le premier obstacle à une évaluation honnête n'est pas juridique, il est psychologique. Une solution connue rassure, une solution inconnue expose celui qui la choisit. Tant que ce réflexe n'est pas neutralisé, les critères de souveraineté restent décoratifs, quelle que soit leur rédaction.

La parade est méthodologique, et elle tient en trois gestes. Construisez la grille d'évaluation à partir des besoins de vos utilisateurs, avant de regarder ce que propose le marché. Faites-la valider par les métiers plutôt que par la seule DSI. Et placez la notoriété du fournisseur tout en bas de la pondération, explicitement, pour que personne n'ait à défendre ce choix en séance.

L'ordre compte. Une grille écrite après avoir consulté le marché reprend le vocabulaire des offres qu'elle vient de lire, et se referme sur elles. Une grille écrite avant décrit un besoin, ce qui laisse une chance aux candidats que l'équipe ne connaissait pas.

Questions à poser aux fournisseurs pour évaluer leur souveraineté numérique

Les questions suivantes ont l'avantage d'appeler des réponses documentaires plutôt que des affirmations.

1. Quelle entité juridique signe le contrat, et quelle est sa chaîne de contrôle capitalistique complète ?
2. Quels sous-traitants ont un accès technique aux données, et depuis quels pays ?
3. Nos contenus peuvent-ils servir à l'entraînement d'un modèle, et pouvons-nous choisir le modèle utilisé ?
4. Quel est le coût chiffré et le délai d'une réversibilité complète, avec export des contenus et des structures ?
5. Quelles certifications couvrent précisément l'environnement qui nous sera livré, et jusqu'à quelle date ?
6. Quel est le préavis contractuel en cas d'arrêt d'une fonctionnalité que nous utilisons ?
7. À quel niveau de l'échelle SEAL du Cloud Sovereignty Framework situez-vous votre offre, et sur quelles pièces ?

Les erreurs à éviter lors de l'intégration de critères de souveraineté

L'erreur la plus fréquente consiste à écrire un critère sans le pondérer. Un critère de souveraineté à 5 % dans une consultation où le prix pèse 60 % ne modifiera aucun classement, et le signal envoyé au marché est celui d'une exigence de façade.

Trois autres pièges reviennent régulièrement. Confondre hébergement et souveraineté conduit à valider une offre dont l'éditeur reste exposé à une législation extraterritoriale. Accepter une déclaration à la place d'une preuve rend le critère invérifiable en cas de contentieux. Enfin, oublier la réversibilité revient à créer la dépendance que la démarche cherchait à éviter, puisque le coût de sortie devient le seul argument de renouvellement du fournisseur sortant.

Un quatrième piège, plus rare et plus coûteux, consiste à écrire une exigence si stricte qu'aucune offre du marché n'y répond. Le rapport sénatorial et la doctrine de l'État convergent sur ce point : une exigence de souveraineté ne vaut que si elle laisse subsister une concurrence réelle.

Où se situe Jahia sur ces critères

Jahia est un éditeur européen de CMS d'entreprise et de plateforme d'expérience numérique, dont le socle est open source. Sur les critères ci-dessus, cela se traduit par un code inspectable et par le choix de l'infrastructure d'hébergement, y compris chez un hébergeur souverain européen.

Côté conformité, la plateforme s'appuie sur une certification ISO/IEC 27001:2022 délivrée par AFNOR et sur une conformité PCI DSS SAQ-D SP. Le périmètre exact de ces certifications, et leur date de validité, sont publiés sur notre page dédiée à la sécurité et à la conformité.

Sur tout le reste, appliquez-nous votre propre grille : cet article est écrit par un éditeur, et c'est une raison de plus d'exiger les pièces plutôt que de croire les déclarations, y compris les nôtres. Aucune plateforme ne répond identiquement aux huit critères, et la pondération que vous retenez déterminera la réponse.

Si votre consultation porte spécifiquement sur un CMS, l'article RGPD et souveraineté : pourquoi le choix de votre CMS compte reprend les mêmes exigences appliquées à cette catégorie de solution.

FAQ sur la souveraineté numérique et les appels d'offres

Une entreprise européenne est-elle forcément souveraine ?

Non. La nationalité de l'éditeur ne garantit rien à elle seule. Une entreprise européenne peut héberger chez un fournisseur soumis à une législation extraterritoriale, appartenir à un actionnaire non européen ou sous-traiter son support hors de l'Union. Ce sont la chaîne capitalistique, le droit applicable au contrat et la localisation effective des accès techniques qui déterminent le niveau réel de souveraineté.

Le Cloud Act s'applique-t-il aux données hébergées en Europe ?

Le CLOUD Act américain de 2018 permet aux autorités des États-Unis de réclamer des données détenues par un fournisseur soumis à leur juridiction, quel que soit le pays de stockage. Héberger en France, en Belgique, au Luxembourg ou en Suisse ne suffit donc pas à écarter une demande. Le texte prévoit des voies de contestation, mais le critère déterminant reste la personne morale qui contrôle l'accès à la donnée, pas l'adresse du centre de données.

Quelle différence entre cloud souverain et cloud de confiance ?

Le cloud souverain désigne une offre dont l'ensemble de la chaîne, capital, exploitation et hébergement, relève du droit européen. Le cloud de confiance désigne une offre opérée en Europe sous licence d'une technologie non européenne, avec des garanties contractuelles et techniques d'étanchéité. Le second réduit l'exposition sans la supprimer, ce qui peut suffire selon la sensibilité des données.

Quelles qualifications exiger selon le pays ?

Nommez-les dans la consultation plutôt que de demander une conformité en général. L'ISO/IEC 27001 est le socle commun reconnu partout, complété par les qualifications nationales et par les exigences de votre autorité de surveillance dans les secteurs régulés. SecNumCloud, qualification française délivrée par l'ANSSI, n'est pas une obligation générale mais s'impose pour les données d'une sensibilité particulière dans la sphère publique. Dans tous les cas, exigez l'attestation elle-même, son périmètre exact et sa date de validité.

Comment évaluer la souveraineté numérique d'un fournisseur ?

En exigeant des preuves documentaires plutôt que des déclarations. Demandez la chaîne capitalistique de l'entité signataire, la liste des sous-traitants ayant un accès technique et leur pays, les attestations de certification avec leur périmètre exact, la nomenclature des composants logiciels, et un plan de réversibilité chiffré. Le Cloud Sovereignty Framework européen fournit une échelle de notation prête à l'emploi pour structurer cette évaluation.

Quels critères intégrer dans un appel d'offres informatique ?

Les huit dimensions décrites ici : souveraineté stratégique, juridique, des données et de l'IA, opérationnelle, chaîne d'approvisionnement, souveraineté technologique, sécurité et conformité, impact environnemental. Chacune doit être assortie d'une preuve exigible et d'une pondération. Un critère écrit sans pondération ni preuve attendue ne discrimine aucune offre. Ces critères se combinent aux critères fonctionnels habituels, détaillés dans notre guide sur comment choisir une plateforme d'expérience digitale.

Sources

1. Commission européenne,Cloud Sovereignty Framework, version 1.2.1, guide d'implémentation, octobre 2025.
2. Commission européenne,Commission advances cloud sovereignty through strategic procurement, 17 avril 2026.
3. DINUM,Achats publics numériques : l'État précise sa doctrine, 6 février 2026.
4. Sénat, commission d'enquête sur les coûts et modalités de la commande publique,rapport n° 830 (2024-2025), tome I, 8 juillet 2025, rapporteur Dany Wattebled.
5. Direction générale des Entreprises,consultation publique sur la souveraineté numérique, 13 mai au 5 juin 2026.
6. Directive 2014/24/UEsur la passation des marchés publics, article 67.
7. Règlement (UE) 2016/679 (RGPD), article 28.
8. Préposé fédéral à la protection des données et à la transparence,décision d'adéquation de l'UE concernant la Suisse, 15 janvier 2024.
9. ANSSI,qualification SecNumCloud.
10. Julian Maurel,"Souveraineté numérique : si elle est stratégique, pourquoi ne pèse-t-elle que 10 % ?", IT for Business, 30 juin 2026.
11. Enquête en ligne réalisée par Infopro Digital Études pour L'Argus de l'assurance et Efficy, du 23 mars au 10 avril 2026, auprès de 412 répondants en France, dont 211 dans l'assurance, 101 dans l'industrie et 100 dans des organismes publics.