Le développement logiciel d’aujourd’hui repose de plus en plus sur des écosystèmes fragmentés. Les équipes maintiennent souvent plusieurs versions d’un même projet comme un dépôt interne pour le développement confidentiel, un dépôt public pour la communauté open source, ou encore des forks spécialisés pour des cas d’usage spécifiques. Mais comment les garder synchronisés sans perdre le fil des modifications, des conflits de fusion ou des règles de gouvernance propres à chaque environnement ? C’est précisément le défi que Copybara, un outil open source développé en interne par Google, permet de relever avec élégance et robustesse.

Loin d’être uniquement un outil de copie, Copybara est une solution conçue pour automatiser la migration, la synchronisation et la transformation de code entre différents systèmes de contrôle de version, tout en préservant l’historique, les métadonnées et les règles spécifiques à chaque dépôt. Contrairement à des solutions manuelles ou à des scripts maison, il offre une approche déclarative, reproductible et sans état. La configuration est définie une fois, puis appliquée de manière cohérente à chaque exécution, que ce soit par un développeur, un service CI/CD ou un bot dédié.

Il peut désigner un dépôt source de vérité (ou authoritative repository). Ce dernier sert de référence absolue, tandis que les autres dépôts peuvent recevoir des contributions ou des correctifs. Lorsqu’une modification est apportée dans un dépôt non autoritaire (par exemple, une contribution externe sur un dépôt public), Copybara peut importer, transformer et fusionner cette modification dans le dépôt source, en gérant les conflits automatiquement comme s’il s’agissait d’une mise à jour classique. Cette fonctionnalité est particulièrement utile pour les projets open source qui acceptent des contributions externes tout en maintenant un dépôt interne maîtrisé.

Des cas d’usage concrets et variés

Les scénarios d’utilisation sont nombreux et couvrent des besoins aussi divers que la gestion de code confidentiel, la synchronisation entre équipes ou la migration vers de nouvelles infrastructures. Par exemple, une entreprise peut utiliser Copybara pour importer des sections de code d’un dépôt privé vers un dépôt public, en filtrant les fichiers sensibles ou en adaptant les chemins pour respecter une structure open source. À l’inverse, elle peut réintégrer des correctifs issus de la communauté dans son dépôt interne, en appliquant des transformations pour les adapter à son environnement.

Autre cas fréquent, la migration de code vers un nouveau système de gestion de version. Que ce soit pour passer de Mercurial à Git, ou pour restructurer un dépôt monolithique en microservices, Copybara permet de déplacer le code tout en conservant l’historique des commits, les auteurs et les messages associés. Grâce à son architecture extensible, l’outil prend en charge Git en natif et offre un support expérimental pour Mercurial, avec la possibilité d’ajouter des connecteurs personnalisés pour d’autres systèmes si nécessaire.

Une approche stateless pour une collaboration sans friction

Parlons maintenant de son modèle stateless. Contrairement à d’autres outils qui nécessitent une base de données centrale ou un état externe pour suivre les synchronisations, Copybara stocke toutes les informations nécessaires directement dans les messages de commit du dépôt de destination, sous forme de labels ou de métadonnées. Cette approche garantit que plusieurs utilisateurs ou services peuvent l’exécuter sur les mêmes configurations et obtenir des résultats identiques, sans risque de désynchronisation. Elle simplifie également la mise à l’échelle, car il n’y a pas de dépendance à un service externe ou à une infrastructure dédiée.

Des transformations puissantes et personnalisables

En plus de pouvoir copier du code, l’outil de Google permet de le transformer en cours de route. À l’aide de règles définies dans des fichiers de configuration (écrits en Starlark, un langage de configuration inspiré de Python), vous pouvez spécifier des opérations telles que le renommage de fichiers ou de répertoires, la modification de chemins dans les fichiers de build (comme les fichiers BUILD de Bazel), ou encore la suppression de fichiers sensibles avant une publication publique. Ces transformations sont appliquées de manière déterministe, ce qui garantit que le code résultant est toujours conforme aux attentes, quelles que soient les modifications apportées en amont.

Copybara est conçu pour s’intégrer de façon naturelle dans les environnements de développement modernes. Il peut être exécuté localement en ligne de commande, intégré dans des pipelines CI/CD, ou même déployé sous forme de service dédié. Google propose des releases hebdomadaires sous forme de binaires précompilés, disponibles sur la page Releases du projet GitHub. Pour les utilisateurs souhaitant travailler avec la dernière version du code, il est possible de compiler Copybara depuis les sources en utilisant Bazel, le système de build open source du géant américain.

L’outil est écrit principalement en Java, ce qui lui confère une portabilité élevée, et il peut être exécuté sur la plupart des systèmes d’exploitation. Une image Docker officielle est également disponible pour faciliter son déploiement dans des environnements conteneurisés.

Pourquoi choisir Copybara plutôt qu’une solution maison ?

Les équipes qui tentent de synchroniser manuellement des dépôts ou qui développent des scripts ad hoc rencontrent rapidement des limites. Les conflits de fusion mal gérés, les erreurs humaines, ou l’absence de traçabilité des modifications peuvent rapidement devenir un casse-tête. Copybara apporte une réponse industrielle à ces problèmes, avec des avantages :

• La fiabilité : en automatisant les synchronisations et les transformations, Copybara réduit les risques d’erreurs humaines et garantit que le code est toujours à jour et conforme aux règles définies.
• La traçabilité : chaque modification est accompagnées de métadonnées qui permettent de remonter à la source, même après plusieurs synchronisations.
• La flexibilité : grâce à son système de configuration déclarative et à son architecture extensible, il peut s’adapter à des workflows avancés et évoluer avec les besoins du projet.
• La collaboration : en permettant à plusieurs acteurs (développeurs, bots, services CI/CD) d’utiliser la même configuration, il facilite la collaboration à grande échelle.

Un projet open source en pleine maturation

Copybara est utilisé en production chez Google depuis plusieurs années, où il joue un rôle clé dans la gestion de projets open source majeurs comme Bazel, Angular ou TensorFlow. Depuis son ouverture au public, il a attiré une communauté active de contributeurs, avec plus de 3 100 étoiles et 315 forks sur GitHub. Le projet est distribué sous licence Apache 2.0, ce qui permet une utilisation libre, y compris dans des contextes commerciaux.

La documentation est encore en cours de finalisation, mais plusieurs ressources sont déjà disponibles pour aider les nouveaux utilisateurs à prendre en main l’outil :

• Une documentation de référence détaillée.
• Des exemples de configurations pour des cas d’usage courants.
• Un tutoriel pour bien démarrer.

Pour les questions ou les retours, l’équipe de Copybara est joignable via une liste de diffusion dédiée.

L’Europe se targue de vouloir briser les monopoles des géants du numérique. Pourtant, avec le déploiement des portefeuilles d’identité électronique (EUDI Wallet), elle s’apprête à commettre une erreur en intégrant dans une infrastructure publique des services de sécurité privés, ceux de Google et d’Apple. Ces outils, présentés comme une garantie contre la fraude, risquent en réalité de verrouiller les citoyens européens dans les écosystèmes fermés des deux géants américains. Une contradiction flagrante avec les valeurs d’ouverture, de souveraineté et d’inclusivité que l’UE prétend défendre.

Le problème saute aux yeux, les portefeuilles numériques, destinés à permettre l’accès aux services publics et à vérifier l’âge en ligne, reposent sur des mécanismes d’attestation à distance contrôlés par Google et Apple. Pour Android, il s’agit de l’API Play Integrity, un service qui vérifie que l’application s’exécute sur un appareil « certifié » et non modifié. Pour iOS, c’est le système Managed Device Attestation d’Apple. Ces technologies, bien que présentées comme des remparts contre les fraudes, servent avant tout les intérêts commerciaux de leurs créateurs.

Prenons l’exemple de Google. Son API Play Integrity est un instrument de contrôle de l’écosystème Android. Officiellement, il permet aux développeurs de s’assurer que leur application tourne sur un appareil légitime, protégeant ainsi contre les bots, les fraudes bancaires ou les triches dans les jeux. Mais dans les faits, il impose une définition très restrictive de ce qu’est un appareil « légitime ». Pour l’entreprise américaine, un terminal est digne de confiance s’il exécute une version licenciée d’Android, si l’application a été installée via le Play Store et si l’utilisateur est connecté à un compte Google.

Autrement dit, cette API exclut de manière délibérée les systèmes d’exploitation alternatifs, comme e/OS ou GrapheneOS, qui se passent des services Google. Pire, elle viole ouvertement le DMA, qui interdit précisément ce type de pratiques anticoncurrentielles.

Pourtant, une alternative existe avec l’API Hardware Attestation d’Android. Celle-ci offre des vérifications matérielles sans imposer les règles de l’écosystème Google. Mais elle est ignorée, au profit d’une solution qui renforce le monopole du géant californien. Les États membres, en adoptant Play Integrity, deviennent ainsi les gardiens des politiques privées de Google, au mépris des principes mêmes de l’interopérabilité et de la souveraineté numérique.

Hypocrisie. L’UE multiplie les discours sur la nécessité de briser l’emprise des GAFAM, mais ses propres États membres, comme les Pays-Bas ou l’Italie, intègrent sans sourciller les outils de Google dans leurs portefeuilles d’identité. Résultat, les utilisateurs de systèmes dégooglisés se voient exclus de services publics essentiels. Comment justifier qu’un citoyen doive accepter les traceurs, les logiciels propriétaires et les modèles de langage intégrés de Google pour accéder à des documents administratifs ou à des services en ligne ? Les portefeuilles d’identité sont des piliers de l’infrastructure publique numérique. Ils doivent être accessibles à tous, indépendamment du système d’exploitation ou du fabricant de l’appareil.

La recherche le confirme. Dans le cadre du projet Mobifree, financé par l’UE, l’organisation Waag a étudié pendant deux ans les freins à l’adoption des écosystèmes mobiles dégooglisés. Parmi les critères décisifs pour les 120 testeurs impliqués figurait la compatibilité avec les applications critiques, comme celles des services gouvernementaux ou des paiements. Si les portefeuilles d’identité numérique ne fonctionnent pas sur GrapheneOS ou e/OS, ces alternatives deviennent tout simplement inutilisables pour une grande partie de la population.

Le manque de cohérence au sein de l’Europe aggrave encore la situation. L’Architecture Reference Framework, le cadre technique européen pour les portefeuilles, ne rend pas l’utilisation de Play Integrity obligatoire, mais la recommande. Certaines interprétations nationales transforment cette recommandation en obligation. L’Italie, par exemple, l’a adoptée sans réserve. La Suisse, en revanche, a choisi de s’appuyer sur le mécanisme d’attestation natif d’Android, abandonnant Play Integrity pour des raisons de protection des données, de souveraineté numérique et de liberté de choix. Preuve que des solutions existent, mais qu’elles sont trop peu exploitées.

Si l’Europe veut vraiment incarner l’autonomie numérique, elle doit interdire purement et simplement l’utilisation des attestations de Google et d’Apple dans son cadre de référence. Les mécanismes ouverts et basés sur le matériel, comme l’API Hardware Attestation, doivent devenir la norme. Les exemples suisses montrent que le recours à Play Integrity n’est ni une fatalité ni une nécessité technique.

La conception des wallets doit être soumise à un débat public et à une responsabilité transparente. Les préoccupations soulevées par les citoyens et les développeurs (comme en témoignent les discussions ouvertes en Allemagne sur GitLab ou en Suisse sur GitHub) méritent une audience bien plus importante que le cercle restreint des experts techniques. Ces enjeux concernent l’ensemble de la société. Le choix nous appartient, mais le temps presse.

L’Internet est sans conteste l’outil de communication le plus puissant jamais créé. Pourtant, depuis ses débuts, son infrastructure a été détournée par une poignée d’acteurs technologiques pour exploiter nos données, capter notre attention et transformer nos vies numériques en produits marchands. Face à cette dérive, la Human-Centered Computing Foundation (HCCF) propose une alternative radicale, créer un nouveau domaine de premier niveau, le .self, entièrement dédié à une tech éthique et centrée sur l’humain.

Officiellement lancée dans le cadre du programme de soutien aux candidats (ASP) de l’ICANN (une organisation à but non lucratif et reconnue d’utilité publique rassemblant des participants du monde entier qui œuvrent à la préservation de la sécurité, la stabilité et l’interopérabilité d’Internet), cette initiative propose de faire un pas important vers un Web où les individus reprennent le contrôle. Plutôt que de subir les algorithmes et les modèles économiques extractifs des géants du numérique, le projet .self envisage une architecture où chaque utilisateur pourrait posséder un espace en ligne souverain, sécurisé et respectueux de sa vie privée.

Le cœur de cette vision repose sur des principes simples. Le domaine .self, loin d’être un espace de noms parmi d’autres, incarne une philosophie où la tech sert les personnes et non l’inverse. Contrairement aux plateformes actuelles, où nos données sont monétisées à notre insu, ce TLD proposerait un cadre technique et juridique garantissant que chaque domaine .self appartient à une seule personne, avec des règles strictes pour éviter la spéculation ou l’usurpation.

L’auto-hébergement serait encouragé, vous permettant de maîtriser pleinement votre présence en ligne, sans dépendre de services tiers souvent opaques.

Pour la HCCF, il s’agit de réinventer les fondements mêmes du Web. Leur pamphlet, disponible en téléchargement, détaille comment ce TLD pourrait intégrer des services décentralisés, comme des messageries chiffrées, des réseaux sociaux sans surveillance de masse, ou encore des outils collaboratifs libres de tout tracking. Le but est d’offrir une alternative concrète aux écosystèmes fermés qui dominent aujourd’hui le paysage numérique.

Bien sûr, un tel projet soulève des questions pratiques. Comment financer une infrastructure de cette envergure ? Comment vérifier qu’un domaine .self est bien attribué à une seule personne ? Comment garantir que cette démarche ne devienne pas, à son tour, un simple label marketing sans impact réel ? La HCCF reconnaît elle-même que le chemin sera long.

Le processus d’évaluation de l’ICANN peut prendre des années et le succès dépendra en grande partie du soutien de la communauté. C’est pourquoi l’organisation appelle déjà à la mobilisation, via des dons, des inscriptions à sa newsletter ou un suivi sur les réseaux sociaux, afin de leur démontrer l’ampleur de l’intérêt pour ce projet.

Peut-être y verrez-vous une part de symbolisme. À l’heure où les scandales liés à la protection des données se multiplient et où la concentration du pouvoir numérique entre les mains de quelques acteurs devient toujours plus préoccupante, le .self représente une lueur d’espoir. Il rappelle que l’Internet n’a pas été conçu pour être un terrain de jeu réservé aux entreprises, mais bien un bien commun à réinventer collectivement.

Reste à savoir si le projet parviendra à concrétiser ses promesses. Les défis sont immenses et l’histoire regorge d’exemples d’initiatives idéalistes étouffées par les réalités économiques ou techniques. Pourtant, l’audace de la HCCF mérite d’être saluée. En osant imaginer un Internet où l’humain passe avant le profit, elle ouvre une brèche dans un système qui semblait jusqu’ici immuable. Et si le .self ne devient jamais une réalité, il aura au moins eu le mérite de nous faire rêver à un Web différent, un Web où nous serions enfin chez nous.

La jungle des systèmes d’exploitation micro-noyau accueille un nouvel acteur prometteur avec QSOE. Développé par Yuri Zaporozhets, ce projet open source (licence Apache 2.0) s’inspire directement de l’architecture épurée et robuste de QNX Neutrino, tout en l’adaptant aux exigences modernes des architectures RISC-V 64 bits. Avec sa première version publique, la 0.1, sortie ce mois de Juin, il propose deux variantes partageant un même espace utilisateur, mais s’appuyant sur des noyaux distincts.

La première variante, QSOE/N, repose sur Skimmer, un micro-noyau conçu de toutes pièces pour ce projet, optimisé pour le multiprocesseur symétrique. La seconde, QSOE/L, utilise quant à elle seL4, le célèbre micro-noyau formellement vérifié, réputé pour sa sécurité et sa fiabilité. Malgré cette dualité, les deux versions offrent une expérience utilisateur identique à 100 %. Seul le gestionnaire de tâches (taskman) et la bibliothèque C (libc.so) diffèrent légèrement, avec un code source partagé à 85 %. Cette cohérence permet aux développeurs de cibler les deux noyaux sans adapter leur logiciel, une prouesse technique qui simplifie grandement l’écosystème.

Une philosophie héritée de QNX avec simplicité et modularité

QSOE perpétue les principes fondamentaux de QNX avec un noyau minimaliste, une communication inter-processus synchrone par passage de messages et un modèle de gestionnaires de ressources pour les services système. Tout ce qui n’est pas nécessaire au noyau est relégué à l’espace utilisateur, ce qui renforce la stabilité, la maintenabilité et la sécurité du système. Cette architecture modulaire permet également une personnalisation fine. Chaque composant peut être remplacé ou étendu sans affecter le reste du système.

Actuellement, l’OS cible principalement les architectures RISC-V 64 bits (RV64, Sv39), avec un support matériel validé sur la carte SiFive HiFive Unmatched (FU740). Le développement quotidien s’effectue cependant sous QEMU, ce qui facilite les tests et les contributions. Les images pré-compilées, disponibles sur GitHub, incluent les binaires des noyaux, les archives CPIO pour l’espace utilisateur, ainsi qu’un chargeur de démarrage maison, mr-bml, compatible UEFI pour RISC-V. Pour une immersion rapide, un simple fichier nvme.img.gz permet de démarrer QSOE sous QEMU, avec un menu de sélection entre les deux variantes.

Une expérience utilisateur déjà aboutie

Dès le premier démarrage, QSOE surprend par sa maturité. Le système propose un terminal interactif avec une invite de connexion (login:), où l’utilisateur peut se connecter en tant que root avec le mot de passe QSOE. L’espace utilisateur inclut déjà un shell, un éditeur de texte, des utilitaires de base, ainsi que des pilotes pour les périphériques essentiels. La documentation, publiée sous forme de PDF aux côtés des versions, est particulièrement complète avec un manuel de conception qui détaille l’architecture à deux noyaux, un guide utilisateur qui explique l’installation et les commandes de base, un livre de programmation qui couvre le développement d’applications (y compris le Resource Server Framework), et un guide de portage qui aide à adapter des logiciels Unix ou QNX existants.

L’installation sur du matériel réel, comme la HiFive Unmatched, suit une procédure simple, il suffit de copier le chargeur mr-bml dans la partition EFI, puis de placer les noyaux et l’espace utilisateur sur une partition ext2/3/4. Un fichier de configuration (mr-bml.cfg) permet de définir les entrées du menu de démarrage, chaque variant pointant vers sa propre partition racine au format fs-qrv, un système de fichiers conçu pour QSOE.

Une feuille de route ambitieuse vers la version 1.0

Contrairement à Linux, dont le développement est souvent perçu comme organique, QSOE se dote d’une feuille de route claire et structurée, divisée en dix versions jalonnant le chemin vers la 1.0. Après la 0.1, qui pose les bases avec un espace utilisateur partagé et un système de fichiers en lecture seule, les prochaines étapes sont déjà tracées. La 0.2 introduira un affichage en mode texte sur GK208 (la puce graphique Kepler de NVIDIA), permettant de visualiser le travail temps réel directement sur l’écran de l’appareil, sans dépendre d’une connexion série. La 0.3 ajoutera des fonctionnalités essentielles au système de fichiers, comme la création et la suppression de fichiers, tandis que la 0.4 marquera l’arrivée d’un gestionnaire de fichiers à double panneau, application phare destinée à démontrer les capacités du système.

Les versions suivantes se concentreront sur des aspects plus avancés : la 0.5 intégrera un périphérique audio (deva-hdmi) et préparera le terrain pour le temps réel strict, avec des mécanismes de priorité, d’interruptions et d’ordonnancement adaptés. La 0.6 verra l’ajout de suites de conformité complètes et d’un package temps réel audio capable de gérer jusqu’à N tâches temps réel sur un système à N cœurs. Plus loin, la 0.8 étendra le support matériel à la carte SpaceMiT K3 (basée sur l’architecture RVA23) et intégrera l’architecture d’interruption AIA (IMSIC/APLIC), assurant une gestion uniforme des interruptions MSI/MSI-X sur différentes cartes. Enfin, la 0.9 poussera la compatibilité avec la bibliothèque C de QNX, permettant de recompiler et d’exécuter des utilitaires QNX existants, avant d’aboutir à la 1.0, première version stable avec une API comparable à QNX 6.x, facilitant le portage de logiciels QNX vers QSOE.

Un écosystème ouvert et des projets complémentaires

QSOE ne se limite pas à son système d’exploitation. Yuri Zaporozhets, à l’origine du projet, a également travaillé sur d’autres initiatives notables, comme QRV, un portage historique de QNX vers RISC-V, ou encore GateMate System/359, une implémentation FPGA d’un système inspiré de l’IBM S/360, complète avec des canaux d’E/S et un macro-assembleur puissant. Ces projets témoignent d’une expertise approfondie en conception de systèmes bas niveau, allant du matériel (FPGA) au logiciel (noyaux, bibliothèques, outils).

Au-delà du développement open source, QSOE Systems propose également des services de conseil et de développement dans des domaines variés comme les systèmes d’exploitation à micro-noyau, les bibliothèques système et runtimes bas niveau, la virtualisation pour applications temps réel, le portage sur RISC-V, ou encore le développement assisté par IA pour les FPGA. Les collaborations peuvent aller de missions ciblées (comme le portage d’un système) à des engagements plus longs, couvrant l’architecture et l’implémentation complète.

Comment essayer QSOE ?

Pour les plus pressés, la méthode la plus simple consiste à télécharger l’image nvme.img.gz depuis les releases GitHub, puis à l’utiliser avec QEMU et le script run-nvme.sh fourni dans le dépôt. Pour les utilisateurs avancés, il est également possible de compiler QSOE depuis les sources à l’aide d’une chaîne d’outils croisés riscv64-linux-gnu- et de make. Le dépôt principal, gitlab.com/qsoe/os, contient toutes les instructions nécessaires.

Pour en savoir plus, consultez le site officiel, explorez les dépôts GitLab, ou contactez directement Yuri Zaporozhets à l’adresse yuriz@qsoe.net. L’aventure ne fait que commencer.