Pourquoi l'open source américain ne nous pose aucun problème

Refuser les services américains tout en utilisant du code écrit aux États-Unis n'est pas contradictoire. Le critère n'est pas l'origine du code mais l'opacité.

Par Thomas Martin · Publié le 4 août 2026

C'est l'objection qu'on pourrait nous adresser, et elle est légitime : si vous refusez les technologies américaines, comment justifiez-vous d'utiliser un noyau Linux, une base de données, un langage et des bibliothèques dont une bonne partie a été écrite aux États-Unis ?

Réponse courte : parce que le critère n'a jamais été l'origine du code.

C'est l'un des six critères examinés dans notre guide LMS souverain : ce que ça veut dire, et celui qui se prête le plus aux malentendus.

Ce que nous refusons, précisément

Nous refusons de confier les données de nos clients à un fournisseur assujetti à un droit extra-européen, au premier rang duquel le CLOUD Act américain, dont nous détaillons la portée ici. C'est tout, et c'est déjà beaucoup.

Ce refus vise des services : hébergement, plateformes en ligne, sous-traitants qui traitent des données pour notre compte. Dans tous ces cas, la donnée est chez quelqu'un d'autre, sous un contrat que nous ne maîtrisons pas entièrement et sous un droit que nous ne choisissons pas.

Il ne vise pas des logiciels que nous exécutons nous-mêmes, sur notre propre infrastructure, et dont nous pouvons lire le code.

La différence tient en trois propriétés

Un logiciel open source est auditable. N'importe qui peut examiner ce qu'il fait, y compris nos clients, y compris un auditeur mandaté par eux. Il n'y a pas de comportement caché possible sur la durée, parce qu'il n'y a pas de secret à garder.

Il est exécutable chez nous. Il n'appelle personne, ne transmet rien, ne dépend d'aucune disponibilité tierce. La donnée reste où nous l'avons mise.

Il est forkable. Si le projet change de licence, de gouvernance ou de direction, la version que nous utilisons continue d'exister et peut être reprise. Il n'y a pas de dépendance contractuelle, donc pas de levier, et donc pas de vendor lock-in (enfermement propriétaire).

Aucune de ces trois propriétés ne dépend du passeport de l'auteur.

Pourquoi un service n'offre aucune des trois

Un service en ligne, à l'inverse, est opaque par construction : vous ne savez pas ce qui tourne, vous constatez des effets. Il s'exécute chez son éditeur, sur son infrastructure, sous son droit. Et il ne se forke pas : le jour où les conditions changent, vous partez ou vous acceptez.

C'est exactement le point que soulève la CNIL le 19 juillet 2024, lorsqu'elle évoque, à propos de la certification européenne des services cloud, le risque d'accès aux données par des autorités d'États tiers pour les hébergeurs dont les sociétés mères sont situées hors de l'Union. Le risque naît de la relation de service et du droit applicable à celui qui la fournit. Il ne naît pas de la nationalité d'un développeur.

L'objection sérieuse : la chaîne d'approvisionnement

Il existe une critique plus solide, qu'il faut prendre au sérieux. Utiliser des milliers de dépendances open source, c'est faire confiance à une chaîne d'approvisionnement logicielle qu'on ne contrôle pas entièrement. Un paquet compromis en amont se propage en aval.

C'est exact, et c'est un vrai sujet de sécurité. Mais ce n'est pas un sujet de souveraineté : le problème serait identique avec des dépendances exclusivement européennes. La réponse est technique et non géographique : verrouillage des versions, revue des mises à jour, réduction du nombre de dépendances.

Confondre les deux mène à une conclusion absurde : réécrire soi-même tout ce qu'on utilise. Personne ne le fait, et personne ne devrait le prétendre.

Ce que cette cohérence nous engage à faire

Si nous considérons que l'auditabilité vaut mieux que la nationalité, alors nous devons l'appliquer à notre propre code.

C'est le sens de notre trajectoire vers un modèle open core : rendre le cœur de la plateforme lisible, vérifiable, et exécutable par qui le souhaite. Ce n'est pas fait aujourd'hui : le code de Magistrae n'est pas ouvert, et nous ne prétendons pas le contraire, comme nous le détaillons dans ce que nous n'avons pas encore rendu souverain. C'est un objectif que nous nous sommes fixé, il découle directement du raisonnement de cet article, et nous expliquons ailleurs pourquoi l'avenir du LMS est auditable.

Un éditeur qui exige la transparence de ses fournisseurs et refuse la sienne tient un discours à géométrie variable. Nous préférons être tenus à ce que nous demandons aux autres.