Un assistant IA peut corriger un bug en quelques minutes, mais il peut aussi proposer une nouvelle bibliothèque comme raccourci. Le diff paraît propre : quelques imports, une ligne dans le manifeste, un test qui passe. Le vrai changement se trouve pourtant ailleurs. L’équipe vient d’ajouter du code qu’elle ne maintient pas, avec ses dépendances transitives, ses scripts d’installation, son rythme de publication et ses risques propres.
La question n’est donc pas seulement de savoir si l’IA a choisi une dépendance populaire ou si la correction fonctionne localement. Pour une équipe de développement, l’enjeu consiste à décider quand un agent ou un assistant a le droit de proposer une installation, quelles preuves doivent accompagner cette proposition et quel contrôle humain reste obligatoire avant la fusion.
Le risque spécifique : l’ajout paraît moins dangereux que la mise à jour
Une mise à jour attire naturellement l’attention : on compare deux versions, on lit un changelog, on vérifie un lockfile. L’ajout d’une dépendance est parfois relu plus vite, parce qu’il semble résoudre un besoin fonctionnel immédiat. C’est précisément le piège. Une nouvelle bibliothèque élargit la surface du projet et crée une relation durable avec un paquet, son mainteneur, son registre et son arbre transitif.
Avec l’IA, ce risque est amplifié par la facilité de suggestion. Un modèle peut privilégier une solution courte à écrire plutôt qu’une solution cohérente avec les dépendances déjà présentes. Il peut aussi proposer une bibliothèque plausible sans connaître les règles internes de l’équipe : licences acceptées, registres privés, politiques de scripts, dépendances abandonnées ou paquets déjà refusés.
Commencer par une règle simple : l’IA peut proposer, pas installer seule
Le point de départ raisonnable est de séparer trois actions : suggérer une dépendance, modifier le manifeste, puis installer et verrouiller la résolution. Un assistant utilisé dans l’IDE peut très bien argumenter pour une bibliothèque. Un agent disposant d’un terminal ne devrait pas exécuter librement l’installation sans cadre explicite, surtout si la commande peut déclencher des scripts ou modifier un lockfile volumineux.
Cette séparation évite de transformer chaque proposition en fait accompli. Elle donne au reviewer une surface claire : pourquoi cette dépendance, pourquoi maintenant, pourquoi celle-ci plutôt qu’une option déjà présente dans le dépôt ?
La fiche minimale à demander à l’assistant
Avant d’accepter une nouvelle dépendance proposée par l’IA, l’équipe peut exiger une fiche courte dans la pull request. Elle ne doit pas ressembler à un dossier d’audit complet. Elle doit rendre la décision relisible.
- Besoin couvert : quel problème précis la dépendance résout.
- Alternative interne : ce qui existe déjà dans le dépôt ou dans la stack.
- Portée : production, développement, test, documentation ou génération.
- Impact manifeste : fichier modifié, dépendance directe ajoutée, changement de lockfile.
- Scripts : présence ou non de scripts d’installation à examiner.
- Maintenance : signes visibles d’activité ou d’abandon, sans inventer de métrique.
- Sortie possible : coût estimé pour retirer la dépendance si elle pose problème.
Le bénéfice est immédiat : l’IA ne se contente plus de produire un diff. Elle prépare les informations que l’humain doit vérifier.
Tableau de décision avant acceptation
Le tableau suivant peut servir de grille de revue. Il ne remplace pas les outils de sécurité, mais il aide à éviter les décisions implicites.
| Point de contrôle | Question à poser | Décision possible |
|---|---|---|
| Dépendance déjà évitable | Le projet possède-t-il déjà une bibliothèque ou une fonction équivalente ? | Refuser l’ajout et demander une solution avec l’existant. |
| Portée d’exécution | La dépendance sera-t-elle utilisée en production ou seulement dans les tests ? | Durcir la revue si elle entre dans le chemin runtime. |
| Scripts d’installation | L’installation exécute-t-elle du code ou modifie-t-elle l’environnement ? | Bloquer l’installation automatique et vérifier manuellement. |
| Arbre transitif | Le lockfile ajoute-t-il un volume difficile à relire ? | Isoler la PR ou demander une justification plus forte. |
| Contrat de maintenance | L’équipe sait-elle qui surveillera les alertes, mises à jour et ruptures ? | Accepter seulement avec un propriétaire identifié. |
| Documentation interne | La raison de l’ajout sera-t-elle compréhensible dans trois mois ? | Exiger une note courte dans la PR ou la documentation technique. |
Créer une liste d’autorisation sans figer l’innovation
Une allowlist trop stricte devient vite contournée. Une absence totale de règle laisse chaque reviewer refaire le même arbitrage. L’équilibre consiste à définir des familles de dépendances autorisées, surveillées ou interdites.
Par exemple, l’équipe peut autoriser les bibliothèques déjà présentes dans l’organisation, demander une revue renforcée pour les paquets qui exécutent des scripts, et refuser par défaut les dépendances qui dupliquent une capacité centrale du framework. Cette règle doit être visible par l’agent IA dans le contexte du dépôt, au même titre que les commandes de test ou les conventions de style.
Ce point complète naturellement le travail de cadrage décrit dans l’article sur le context engineering pour agents IA : une consigne utile n’est pas seulement une préférence de code, c’est aussi une limite opérationnelle.
Traiter le lockfile comme un document de sécurité
Quand l’IA ajoute une dépendance, le lockfile raconte souvent plus que le manifeste. Il montre l’arbre réellement résolu, les paquets transitifs et parfois un changement beaucoup plus large que prévu. Le reviewer ne doit pas forcément tout lire ligne par ligne, mais il doit vérifier que la taille et la nature du changement restent cohérentes avec la demande initiale.
Si l’ajout entraîne une cascade difficile à justifier, la bonne réponse n’est pas de demander à l’IA de reformuler sa justification. Il faut réduire le périmètre, chercher une alternative déjà installée ou isoler la dépendance dans une PR dédiée. L’article sur les mises à jour de dépendances proposées par l’IA traite ce sujet côté versioning ; ici, le même réflexe s’applique dès la première installation.
Empêcher les installations opportunistes dans les tâches floues
Les dépendances inutiles apparaissent souvent dans les tickets mal bornés : “améliorer le parsing”, “nettoyer la validation”, “rendre l’export plus robuste”. Si l’objectif n’est pas testable, l’assistant peut choisir une bibliothèque comme solution rapide, alors qu’un ajustement local suffisait.
Une règle utile consiste à interdire l’ajout de dépendance dans les tickets dont le résultat attendu n’est pas vérifiable. L’agent peut alors proposer une option dans son rapport, mais il ne modifie pas le manifeste. Cette décision rejoint le triage décrit dans l’arbre de décision avant délégation à un agent IA : certaines tâches doivent rester en analyse avant de produire un diff.
Ce que la documentation technique doit conserver
Une dépendance acceptée grâce à l’IA ne doit pas rester seulement dans l’historique Git. L’équipe gagne à conserver une trace courte : raison de l’ajout, alternatives écartées, propriétaire de maintenance, commandes de vérification et conditions de retrait. Cette documentation n’a pas besoin d’être longue. Elle doit surtout empêcher que la même discussion recommence à chaque alerte ou refactorisation.
La bonne place dépend du dépôt : description de pull request, ADR léger, fichier de dépendances approuvées, ou section dédiée dans la documentation technique. Le format importe moins que la capacité à retrouver la décision.
Checklist avant merge
- La dépendance répond à un besoin précis et testable.
- Une alternative déjà présente dans le projet a été envisagée.
- La portée runtime, dev ou test est explicite.
- Le manifeste et le lockfile ont été relus séparément.
- Les scripts d’installation ne sont pas acceptés par automatisme.
- La justification de l’IA est vérifiée par un humain.
- Un propriétaire de maintenance est identifié.
- La PR explique comment retirer la dépendance si nécessaire.
Le bon indicateur de maturité
Une équipe mature ne cherche pas à empêcher toute nouvelle dépendance. Elle cherche à rendre chaque ajout explicable, limité et réversible. Si l’IA accélère la rédaction du code mais multiplie les bibliothèques sans mémoire de décision, le gain initial se transforme en dette de maintenance.
Le bon indicateur n’est donc pas le nombre de dépendances refusées. C’est la proportion d’ajouts pour lesquels un reviewer peut comprendre rapidement le besoin, la portée, les risques et le plan de maintenance. À ce niveau, l’assistant IA reste utile : il prépare la comparaison, génère les tests, documente la décision. Mais il ne devient pas l’autorité qui agrandit seule la surface logicielle du dépôt.
dans votre équipe, une IA peut-elle proposer une nouvelle dépendance ou doit-elle d’abord passer par une règle d’autorisation explicite ?
Publié dans la discussion