Mouvement 0deps : Dépendances locales et contrats immuables
Les développeurs de logiciels installent souvent des centaines de bibliothèques externes. Les frameworks modernes reposent sur des milliers de dépendances transitives. Cela signifie que votre application exécute du code provenant d'inconnus.
Cela crée un risque pour la chaîne d'approvisionnement logicielle.
Chaque dépendance augmente votre surface d'attaque. Elle peut :
- Introduire des failles de sécurité.
- Devenir une cible pour des attaques de la chaîne d'approvisionnement.
- Être abandonnée par ses mainteneurs.
- Modifier son API publique.
- Rompre la compatibilité ascendante.
Le mouvement 0deps pose une question simple : et si votre application ne reposait que sur du code que vous contrôlez ?
Dans le modèle 0deps, vous intégrez les dépendances nécessaires directement dans le dépôt de votre projet. Vous cessez de les télécharger dynamiquement lors des builds. Tout ce qui est nécessaire au fonctionnement de l'application reste dans le dépôt dès le départ.
Cette approche offre :
- Des builds reproductibles.
- Moins de dépendance vis-à-vis des registres externes.
- Des audits de sécurité centralisés.
- Une plus grande prévisibilité.
Le principe fondamental n'est pas de garder le code statique. Les implémentations et les algorithmes doivent évoluer pour corriger des bugs et améliorer la sécurité. Ce qui reste stable, c'est le contrat public.
Chaque bibliothèque expose une interface soigneusement conçue. Par exemple :
authenticate()createSession()verifyPasskey()
Ces fonctions définissent un contrat. Le contrat ne change jamais. Vous pouvez réécrire le code sous-jacent ou remplacer entièrement la bibliothèque. Le reste de votre application ne remarquera pas le changement.
Lorsqu'une vulnérabilité apparaît, vous êtes généralement confronté à deux problèmes :
- Corriger la faille.
- Vérifier si la mise à jour casse votre application.
Dans une architecture 0deps, le second problème disparaît. Vous mettez à jour l'implémentation interne tandis que l'API publique reste la même. Votre application continue de fonctionner sans modification de code.
Vous isolez les intégrations externes à l'aide d'un adaptateur interne : Application -> Interface publique -> Adaptateur -> Implémentation
Si une bibliothèque disparaît demain, vous n'avez qu'à changer l'adaptateur. Aucune autre partie de votre application ne sera affectée.
Le 0deps ne rend pas le logiciel parfait. Il réduit les risques liés à la chaîne d'approvisionnement. Il prévient des problèmes tels que les paquets malveillants, les compromissions de registres et la confusion de dépendances.
Les projets durent des décennies. Les bibliothèques et les frameworks changent. Avec 0deps, votre application continue d'utiliser les mêmes contrats stables, quelle que soit l'évolution de l'écosystème.