Ne mettez jamais les dépendances à jour en premier

Le réflexe qui semble raisonnable, et qui ne l'est pas

Un dirigeant qui hérite d'un projet de code, qu'il ait été écrit par un freelance parti, une équipe précédente, ou généré à grande vitesse avec l'aide d'une IA, ressent presque toujours la même urgence en premier : rattraper le retard technique visible. Les dépendances n'ont pas été mises à jour depuis des mois, la version du langage accuse un retard, des alertes de sécurité s'accumulent dans les outils de suivi. Ce retard est concret, chiffrable, il donne l'impression de savoir exactement par où commencer. C'est précisément ce qui en fait un mauvais point de départ.

Mettre à jour des dépendances sur un projet dont personne ne maîtrise encore parfaitement le comportement revient à changer les fondations d'une maison sans savoir quels murs elles portent. Une mise à jour de version peut modifier silencieusement un comportement dont dépendait, sans que ce soit documenté nulle part, une fonctionnalité critique.

Le scénario se répète avec une régularité frappante. Une équipe reprend un projet, lance une série de mises à jour de bibliothèques en début de semaine pour repartir sur des bases saines, et découvre quelques jours plus tard qu'un parcours de paiement ou une notification client ne fonctionne plus. Personne ne sait dire, à ce stade, si le problème vient de la mise à jour ou s'il existait déjà avant, dissimulé par un usage qui ne l'avait jamais déclenché. Cette incertitude transforme une opération de maintenance de routine en enquête, souvent plus coûteuse en temps que la mise à jour elle-même n'était censée en faire gagner.

Pourquoi la mise à jour semble urgente alors qu'elle ne l'est pas

La mise à jour des dépendances est attirante parce qu'elle se mesure facilement : un nombre de paquets obsolètes, un score de sécurité, une jauge qui progresse visiblement à chaque mise à jour effectuée. Stabiliser un comportement existant, à l'inverse, ne produit aucune métrique gratifiante à court terme. On ne peut pas facilement montrer, en fin de semaine, le travail de compréhension effectué sur un parcours utilisateur critique. Cette asymétrie de visibilité pousse à traiter en premier ce qui se mesure, pas ce qui protège.

Le problème s'aggrave avec du code généré rapidement par IA, une situation de plus en plus fréquente pour les projets qui arrivent sur le bureau d'un dirigeant quelques mois après leur lancement. Ce code fonctionne souvent en apparence, sans que son auteur d'origine, humain ou non, n'ait laissé de trace des décisions implicites qu'il contient.

Une IA générative ne documente jamais spontanément pourquoi elle a choisi telle approche plutôt qu'une autre, elle produit un résultat qui fonctionne sur le cas testé, sans garder de trace du raisonnement qui l'a produit. Un développeur humain qui reprend ce code ne peut donc pas s'appuyer sur des commentaires ou des choix explicites pour deviner ce qui est structurant et ce qui est accessoire. Toute intervention devient, par défaut, une expérimentation dont l'issue reste incertaine tant qu'un filet de sécurité minimal n'a pas été posé. Sur les signaux qui permettent de reconnaître ce type de code avant même d'en hériter, notre analyse de la dette technique invisible produite par le vibe coding détaille ce qu'il faut chercher.

« On voit aussi beaucoup de produits qui ont de moins en moins de stabilité en production, parce que l'IA vient créer aussi parfois de la dette technique. Donc on essaie de trouver le juste curseur. »

L'ordre qui protège contre la régression silencieuse

Chez Leando, ce principe s'appelle stabiliser avant d'étendre. Face à un code hérité, la première action ne doit jamais être celle qui semble la plus urgente en apparence, mettre à jour ce qui est visiblement en retard, mais celle qui protège contre la régression silencieuse : figer ce qui fonctionne aujourd'hui, se donner un moyen de détecter si on vient de le casser, puis seulement toucher à la structure ou aux versions. Le principe exclut d'attendre une couverture de tests complète avant de commencer, un objectif irréaliste sur un projet hérité, mais il exclut tout autant de tout mettre à jour d'un coup pour rattraper le retard affiché.

Trois mouvements, dans cet ordre précis

Le premier mouvement consiste à geler les dépendances telles quelles, exactement dans l'état où le projet vous a été transmis, le temps de comprendre ce qui fonctionne réellement. Le deuxième consiste à documenter, même sommairement, le comportement attendu des deux ou trois parcours qui font tourner l'activité : que doit-il se passer, précisément, quand un client passe une commande ou signe un document. Cette liste, même tenue à la main sans outil automatisé, devient la référence qui permet de détecter une régression après coup. Le troisième mouvement, seulement après les deux premiers, consiste à toucher à la structure du code ou à envisager des mises à jour, une dépendance à la fois, jamais toutes en même temps.

Cet ordre n'a rien d'évident quand on découvre un projet pour la première fois. L'impression dominante, face à un tableau de bord qui affiche vingt paquets en retard et trois alertes de sécurité, est que chaque jour d'attente aggrave le risque. C'est vrai pour le risque de sécurité pur, beaucoup moins vrai pour le risque de régression fonctionnelle, qui lui augmente au contraire avec la précipitation. Distinguer ces deux risques, et accepter de laisser le second attendre pendant qu'on traite le premier séparément si nécessaire, est ce qui différencie une reprise de projet maîtrisée d'une reprise qui multiplie les incidents.

Sur la question complémentaire de la priorisation, une fois l'audit lancé, entre ce qui doit absolument tenir en production et ce qui peut attendre, notre méthode pour reprendre un projet dans les 30 jours qui suivent le départ d'un freelance détaille comment trancher par impact business plutôt que par propreté du code, une fois que le socle est stabilisé.

Pourquoi ce filet minimal suffit, même sans équipe technique interne

Une objection revient systématiquement face à cette méthode : une PME sans équipe technique interne n'a ni le temps ni les compétences pour documenter des parcours critiques avant de laisser un prestataire toucher au code. Cette objection confond deux niveaux d'exigence très différents. Documenter un parcours critique ne demande pas de compétence technique, cela demande de savoir décrire, en tant que dirigeant ou responsable métier, ce qui doit se passer quand un client passe commande, paie, ou reçoit une confirmation. Cette description peut se faire en une page, dans un langage entièrement business, sans une ligne de code.

C'est d'ailleurs souvent le dirigeant ou le responsable opérationnel, pas le développeur, qui est le mieux placé pour établir cette liste, parce qu'il connaît le résultat attendu mieux que quiconque n'a eu le temps de le documenter côté technique. Une fois cette liste écrite, elle devient un cahier des charges minimal que n'importe quel prestataire, interne ou externe, peut utiliser pour vérifier qu'il n'a rien cassé avant de livrer une évolution.

Ce que ce principe n'excuse pas

Stabiliser avant d'étendre ne justifie pas de repousser indéfiniment la mise à niveau d'un projet. Une dépendance dont une faille de sécurité connue est activement exploitée doit être traitée immédiatement, indépendamment de l'ordre décrit ici, parce que le risque qu'elle fait courir dépasse celui d'une régression fonctionnelle. Il exclut également l'excuse consistant à ne jamais mettre à jour par prudence excessive, année après année, jusqu'à ce que la dette rende toute évolution impossible sans réécriture complète.

Construire un projet avec zéro dette technique reste, de toute façon, un objectif utopique. Un peu de dette accompagne tout projet qui avance vite, ce n'est pas en soi le signe d'un problème. Ce qui distingue un projet gérable d'un projet qui dérape n'est pas la quantité de dette accumulée, c'est l'ordre dans lequel on choisit de la traiter : jamais en commençant par ce qui casse silencieusement un comportement qu'on ne comprend pas encore. Un projet avec une dette connue et cartographiée reste plus sain, à ce titre, qu'un projet fraîchement mis à jour dont personne ne peut garantir le comportement.

La prochaine fois que vous héritez d'un projet et que la première alerte de sécurité vous pousse à vouloir tout mettre à jour dans la semaine, prenez d'abord le temps de savoir ce que le projet fait réellement aujourd'hui. Cette semaine de patience apparente est ce qui évite les cinq semaines de correction qui suivent une mise à jour lancée trop tôt, et c'est aussi ce qui vous permet de reprendre une vraie visibilité sur un projet que vous n'avez pas construit vous-même, avant de décider où investir en premier.