Publier vos choix de stack technique et le raisonnement de souveraineté qui les sous-tend#
De quoi s’agit-il concrètement#
Cet engagement consiste à publier, sur votre site personnel, sur un dépôt public ou sur un blog, votre stack technique de prédilection et le raisonnement qui la sous-tend du point de vue de la souveraineté. Le document explicite vos choix par catégorie (forge, langage, framework, base de données, hébergement, outils de développement, IDE, etc.), nomme les solutions retenues, et explique pourquoi vous les avez retenues — en intégrant explicitement la dimension de gouvernance, de juridiction et de modèle de financement.
Le document n’est pas un manifeste idéologique. Il vise à documenter vos arbitrages réels, y compris les compromis. Si vous utilisez encore GitHub pour des raisons d’effet de réseau professionnel mais que vous démarrez vos nouveaux projets sur Codeberg, dites-le. Si vous codez en TypeScript malgré la gouvernance Microsoft parce que vous estimez que l’écosystème est mature, expliquez le raisonnement. La transparence sur les compromis vaut plus que la pureté de façade.
L’engagement vaut comme déclaration individuelle. Il porte sur votre stack personnelle et professionnelle dans la mesure où vous avez le contrôle sur les choix. Pour les missions où la stack est imposée, vous pouvez documenter ce que vous recommanderiez si vous aviez le choix.
Pourquoi cet engagement compte#
La pédagogie de l’écosystème dépend largement des praticiens qui rendent visibles leurs raisonnements. Une thèse abstraite (la thèse 6 sur la chaîne entière, la thèse 8 sur les mainteneurs, la thèse 12 sur le rôle des fournisseurs européens) gagne en force quand elle est incarnée dans des choix concrets de stack documentés par des praticiens en activité. Vos lecteurs — collègues, clients potentiels, étudiants, débutants — peuvent ensuite se former leur propre jugement à partir d’éléments concrets.
L’engagement résonne avec l’esprit général du manifeste : la souveraineté n’est pas une déclaration mais une chaîne d’arbitrages quotidiens. Quand vous documentez votre stack, vous montrez à quoi ressemble cette chaîne d’arbitrages dans la vraie vie. La thèse 11 du manifeste — « une politique sérieuse de souveraineté numérique européenne se reconnaît à son investissement dans les fondations, les mainteneurs et les infrastructures de distribution » — se traduit par les choix concrets que vous documentez.
Pour vous, l’engagement a un effet réflexif. Le simple fait de devoir publiquement justifier vos choix vous oblige à les examiner avec rigueur. Beaucoup de développeurs découvrent, en rédigeant leur stack publiée, des incohérences ou des choix par défaut qu’ils n’avaient pas conscientisés. Le document devient à la fois pédagogique et autodisciplinaire.
Exemple concret de mise en œuvre#
Une développeuse fullstack basée à Lyon, freelance et active dans la communauté Python locale, prend cet engagement en mars 2026 avec un horizon de 6 mois. Elle rédige en parallèle de ses missions un article structuré qu’elle publie sur son blog personnel en septembre 2026 : « Ma stack technique en 2026 — choix et raisonnement de souveraineté ».
L’article fait environ 3 500 mots et couvre dix catégories : forge (Codeberg pour les nouveaux projets, GitHub conservé pour les projets clients existants, avec explication), langages principaux (Python via PSF / fondation neutre, TypeScript en pleine conscience du compromis Microsoft), bases de données (PostgreSQL en première intention, SQLite pour les petits besoins, mention explicite de l’éviction de MongoDB et de l’évaluation de Valkey contre Redis), hébergement (Scaleway pour les projets personnels, OVHcloud ou Hetzner selon les missions), outils de productivité (LibreOffice, Nextcloud auto-hébergé, ProtonMail), IDE (VSCodium plutôt que VS Code, choix expliqué), terminal et shell (alacritty + tmux, fish), CI/CD (Forgejo Actions sur Codeberg pour les nouveaux projets), monitoring (Grafana avec mention de la bascule AGPL d’avril 2024), gestion de paquets (uv pour Python, attention à la gouvernance Astral américaine).
L’article est partagé sur les réseaux professionnels et reçoit plusieurs centaines de visites en deux mois. Trois autres développeurs publient leur propre stack documentée dans la foulée. La développeuse met l’article à jour annuellement.
Anti-pattern à éviter#
Une publication qui ressemble à un panégyrique de l’open source européen sans nuance ni mention des compromis manque de crédibilité technique. Symétriquement, une publication qui se contente de lister les outils sans expliquer le raisonnement ne sert pas la pédagogie. La valeur de l’engagement tient à la combinaison de l’explicitation des choix, de l’honnêteté sur les compromis, et de la mise à jour dans le temps.
Indicateurs de réussite#
À l’horizon de 6 mois, vous pouvez raisonnablement considérer cet engagement tenu si une publication accessible publiquement (blog, site personnel, dépôt) documente votre stack technique avec un raisonnement de souveraineté pour chaque choix substantiel. À long terme, l’engagement prend forme avec la mise à jour annuelle de la publication et la prise en compte des évolutions de gouvernance des composants.
Catégorie dans le schéma JSON : publication. Horizon par défaut : 6 mois. Applicable à : déclarations individuelles uniquement.