L'IA pourra-t-elle remplacer les gestionnaires de paquets ? Du npm à un registre de prompts

Un auteur tech russe de Habr a décortiqué une idée avancée par le développeur Marcelo Emmerich dans un billet sur Medium : remplacer les gestionnaires de paquets traditionnels comme npm par un « registre de prompts », un système où les auteurs de bibliothèques publient non pas du code prêt à l'emploi, mais des prompts destinés à une IA qui génère une implémentation autonome directement chez le développeur.

En quoi consiste l'idée du « registre de prompts »

Selon Emmerich, au lieu d'installer une bibliothèque toute faite avec npm install, le développeur colle le prompt de l'auteur de la bibliothèque dans son outil d'IA, qui génère la fonctionnalité sur place, adaptée au langage de programmation et aux particularités du projet. Comme le note l'auteur de Habr, cette approche a une logique séduisante : si le code est régénéré pour chaque tâche, les dépendances transitives (les bibliothèques qu'une autre bibliothèque entraîne avec elle), les attaques sur la chaîne d'approvisionnement (supply chain attacks) via des paquets compromis et les conflits entre versions des différentes dépendances d'un même projet disparaissent. Ce sont les points douloureux classiques du développement moderne.

Pourquoi la proposition est naïve, mais pas sans fondement

L'auteur de Habr qualifie l'idée de naïve, mais admet qu'elle pointe de vrais problèmes. Les attaques sur la chaîne d'approvisionnement, c'est-à-dire l'injection de code malveillant via une dépendance compromise au fond de l'arbre de paquets, sont une menace sérieuse et difficile à maîtriser : savoir ce que contiennent exactement toutes les dépendances transitives d'un gros projet est pratiquement impossible à la main. L'idée de « générer exactement ce qu'il faut, sans rien de superflu » séduit aussi à sa manière, car elle promet de mettre fin au gonflement des applications modernes, qui traînent des dizaines de mégaoctets de code inutilisé à travers des chaînes de dépendances.

Points clés de l'analyse :

• L'idée originale vient de Marcelo Emmerich, dans un billet publié sur Medium.
• Le remplacement proposé aux gestionnaires de paquets est un « registre de prompts » pour générer du code sur place.
• Les avantages revendiqués : pas de dépendances transitives, protection contre les attaques sur la chaîne d'approvisionnement, pas de conflits de versions.
• Contre-argument de l'auteur de Habr : la complexité (TLS, analyse de JSON, Unicode) ne disparaît pas, elle cesse simplement de s'appeler « dépendance ».

Ce que cette idée ne prend pas en compte

Le principal contre-argument de l'auteur de Habr porte sur la nature de la complexité logicielle. Même si chaque développeur régénère la fonctionnalité de base (chiffrement TLS, analyse du format JSON, gestion correcte d'Unicode), cette complexité ne s'évapore pas. Elle passe d'une bibliothèque publique, écrite une fois et vérifiée de nombreuses fois par la communauté, à des milliers d'implémentations parallèles générées indépendamment, chacune pouvant receler ses propres bugs et vulnérabilités. Autrement dit, renoncer à la notion de « dépendance » n'élimine pas la tâche elle-même, qui consiste à implémenter une logique complexe et sujette aux erreurs ; cela change seulement qui la résout, et quand.

Cela ramène au compromis fondamental des écosystèmes open source : les bibliothèques centralisées et très utilisées, malgré tous leurs risques pour la chaîne d'approvisionnement, bénéficient de l'effet d'échelle. Des milliers d'yeux examinent le même code, et les bugs sont trouvés et corrigés une seule fois pour tout le monde. Le modèle « régénérer pour chaque projet » perd au contraire ces tests collectifs, en échange de la personnalisation et de l'absence de dépendances externes. On ignore si l'échange est rentable, surtout pour la logique d'infrastructure critique comme la cryptographie ou l'analyse de protocoles réseau, où le prix d'une erreur est élevé et où les cas limites rares sont difficiles à anticiper lors d'une génération de code unique.

L'écosystème npm, que Marcelo Emmerich mentionne dans son texte, rassemble des millions de paquets et reste le plus grand registre au monde pour le développement JavaScript. C'est aussi l'une des cibles les plus fréquentes des attaques sur la chaîne d'approvisionnement, où des pirates publient des versions malveillantes de paquets populaires ou au nom proche, en espérant que des développeurs ou des systèmes de build automatisés les installent par erreur. C'est précisément cette longue expérience de lutte contre ces incidents qui explique pourquoi l'idée d'abandonner complètement le code partagé au profit d'une génération « à partir de zéro » séduit une partie de la communauté, même si, comme le montre l'analyse de Habr, elle déplace le problème de la complexité vers un endroit nouveau et moins éprouvé au lieu de le résoudre.