Pendant des années, l'industrie du logiciel a adopté une culture consistant à installer des dizaines, voire des centaines, de bibliothèques externes dans presque tous les projets. Les frameworks modernes reposent souvent sur des milliers de dépendances transitives, ce qui signifie qu'une seule application peut finalement dépendre de code maintenu par des centaines de contributeurs inconnus.
Si cet écosystème a considérablement accéléré le développement logiciel, il a également introduit une nouvelle catégorie de risques : la chaîne d'approvisionnement logicielle (Software Supply Chain).
Le Mouvement 0deps naît d'une question simple :
Et si une application ne dépendait que du code qu'elle contrôle réellement ?
Le problème des dépendances
Chaque dépendance augmente la surface d'attaque.
Elle peut :
- Introduire des vulnérabilités de sécurité.
- Être la cible d'une attaque de la chaîne d'approvisionnement.
- Être abandonnée.
- Modifier son API publique.
- Supprimer des fonctionnalités.
- Rompre la rétrocompatibilité.
- Ajouter de nouvelles dépendances transitives.
- Publier des versions incompatibles.
En pratique, les développeurs perdent le contrôle d'une partie importante du code exécuté en production.
Plus l'arbre des dépendances est grand, plus la surface d'attaque potentielle est importante.
La proposition
Dans le modèle 0deps, toutes les dépendances nécessaires sont intégrées directement au dépôt du projet.
Les dépendances ne sont plus téléchargées dynamiquement par les gestionnaires de paquets lors de l'installation ou de la compilation.
Tout ce qui est nécessaire pour construire et exécuter l'application est déjà présent dans le dépôt dès son clonage.
Cela apporte plusieurs avantages majeurs :
- Des compilations reproductibles.
- Une dépendance réduite aux registres de paquets externes.
- Un audit de sécurité centralisé.
- Une meilleure prévisibilité.
- Une réduction de la surface d'attaque de la chaîne d'approvisionnement.
Des contrats publics immuables
Le principe fondamental de 0deps n'est pas de figer les implémentations.
Les implémentations évoluent.
Les algorithmes évoluent.
Les correctifs de sécurité évoluent.
Ce qui reste stable, c'est le contrat public.
Chaque bibliothèque expose une interface publique soigneusement conçue.
Par exemple :
authenticate()
createSession()
verifyPasskey()
sendMagicLink()
Ces fonctions définissent un contrat.
Ce contrat ne change jamais.
L'implémentation sous-jacente peut être entièrement réécrite.
Les algorithmes peuvent évoluer.
Les bibliothèques internes peuvent être remplacées.
Les protocoles peuvent évoluer.
Les structures de données peuvent être repensées.
Aucun de ces changements internes n'affecte la manière dont le reste de l'application utilise la bibliothèque.
Des mises à jour de sécurité sans casser les applications
Lorsqu'une vulnérabilité est découverte, deux préoccupations apparaissent généralement :
- Corriger la vulnérabilité.
- Déterminer combien d'applications seront affectées par la mise à jour.
Dans l'architecture 0deps, cette seconde préoccupation disparaît presque entièrement.
Les mises à jour se font en interne.
L'implémentation derrière l'interface est modifiée.
L'API publique reste exactement identique.
Les applications continuent de fonctionner sans aucune modification de leur code.
Autrement dit, l'implémentation évolue tandis que le contrat demeure stable.
Des adaptateurs internes
Toute intégration externe est isolée derrière un adaptateur interne.
Application
↓
Interface publique
↓
Adaptateur
↓
Implémentation
Si une bibliothèque externe devient obsolète ou disparaît demain, seul l'adaptateur devra être modifié.
Aucune autre partie de l'application ne sera impactée.
Cette isolation réduit considérablement l'impact des évolutions technologiques.
Un versionnement invisible
Les applications construites selon le modèle 0deps n'interagissent jamais directement avec les API des bibliothèques externes.
Elles communiquent uniquement avec des contrats internes stables.
Les versions des bibliothèques deviennent un simple détail d'implémentation.
Les mainteneurs du framework prennent en charge les mises à jour.
Les développeurs d'applications continuent d'utiliser exactement la même interface, indépendamment des changements internes.
Sécurité de la chaîne d'approvisionnement
L'objectif de 0deps n'est pas de prétendre que les logiciels deviennent invulnérables.
Son objectif est de réduire significativement les risques liés à la chaîne d'approvisionnement logicielle.
En supprimant l'installation dynamique des dépendances lors de la compilation, l'architecture réduit l'exposition à des menaces telles que :
- La publication de paquets malveillants.
- La compromission des registres de paquets.
- Les attaques de dependency confusion.
- Les paquets de typosquatting.
- Les modifications inattendues des dépendances transitives.
Tout le code exécutable fait désormais partie intégrante du projet, ce qui permet un audit, un versionnement et une revue de sécurité centralisés.
Une stabilité à long terme
Le principal avantage de 0deps apparaît véritablement plusieurs années après la mise en production d'un projet.
Les projets vivent pendant des décennies.
Les bibliothèques disparaissent.
Les frameworks évoluent.
Les écosystèmes changent.
Malgré cela, les applications continuent d'utiliser exactement les mêmes contrats publics.
La responsabilité de suivre l'évolution de l'écosystème est centralisée dans les adaptateurs internes du projet plutôt que répartie entre toutes les applications qui en dépendent.
Les mises à jour potentiellement perturbatrices deviennent de simples remplacements d'implémentation.
Le Mouvement
Le Mouvement 0deps n'est pas opposé aux logiciels open source.
Bien au contraire.
Il reconnaît leur immense valeur tout en proposant un modèle de consommation différent.
Les bibliothèques ne sont plus considérées comme des dépendances installées dynamiquement.
Elles deviennent des composants intégrés au projet, audités, versionnés et encapsulés derrière des contrats publics stables.
Le résultat est un logiciel plus prévisible, plus résilient, plus facile à maintenir et significativement moins exposé aux risques de la chaîne d'approvisionnement.
Les implémentations peuvent évoluer indéfiniment.
Le contrat, lui, reste inchangé.
Et c'est précisément cette stabilité qui permet aux applications développées aujourd'hui de continuer à fonctionner exactement de la même manière pendant de nombreuses années.
Top comments (0)