Organisez les mises à jour des dépendances avec un inventaire, des priorités explicites et des tests adaptés aux parcours utilisés par votre entreprise.
Une bibliothèque doit être mise à jour, mais personne ne sait si elle est utilisée directement par l’application ou introduite par un autre composant. L’équipe reporte la décision, puis découvre plusieurs mois plus tard un ensemble de changements difficiles à isoler. Un suivi régulier permet de traiter ces décisions par périmètre identifiable.
Commencez par connaître la version réellement déployée. La liste déclarée dans le projet, la résolution des dépendances et le résultat installé peuvent apporter des informations différentes. La procédure de construction doit permettre de relier ces éléments à une livraison précise.
Identifier les dépendances et leurs propriétaires
Demandez au prestataire de présenter les bibliothèques principales, le langage d’exécution et les outils de construction. Ajoutez les composants de l’image ou du serveur que votre contrat met à sa charge. Le périmètre doit être clair pour éviter qu’une mise à jour soit supposée prise en charge par l’hébergeur alors qu’elle ne l’est pas.
Dans un projet npm, le fichier package-lock.json décrit l’arbre de dépendances résolu. Il permet de conserver les versions retenues et doit être examiné avec les changements du manifeste. D’autres écosystèmes ont leurs propres mécanismes ; utilisez leur documentation et la procédure de construction du projet.
Attribuez un responsable aux notifications et aux décisions. Une alerte reçue uniquement par un ancien développeur ne déclenche aucune action. Conservez un moyen de joindre le mainteneur actuel et précisez les périodes pendant lesquelles il s’engage à examiner les demandes.
Séparer l’urgence du travail planifié
Une mise à jour peut corriger une vulnérabilité, résoudre un défaut fonctionnel ou préparer une évolution du framework. Ces motifs demandent des délais et des contrôles différents. Lisez l’avis ou les notes de version correspondant au composant concerné avant de décider.
Pour une alerte de sécurité, vérifiez la version affectée et l’usage du composant dans l’application. Une qualification technique aide à déterminer la réponse, mais elle ne doit pas servir à ignorer durablement un problème non analysé. Documentez l’incertitude restante et sollicitez une expertise adaptée si l’équipe ne peut pas conclure.
Pour les mises à jour courantes, choisissez un créneau de maintenance et un volume que l’équipe peut relire. Regroupez des composants liés lorsque le fournisseur le demande, puis évitez d’ajouter des changements fonctionnels sans rapport dans la même livraison. Cela simplifie l’attribution d’une régression éventuelle.
Utiliser l’automatisation pour préparer la revue
Dependabot peut proposer des demandes de mise à jour selon une configuration et un calendrier. L’outil prend en charge des écosystèmes déterminés et ses propositions doivent être examinées dans le contexte du projet. Une demande automatiquement créée ne prouve pas que l’application fonctionne avec la nouvelle version.
Définissez qui traite ces propositions et ce qu’il doit vérifier avant de les fusionner. Si elles s’accumulent, examinez la capacité de revue et les règles de regroupement. Un outil qui ouvre plus de demandes que l’équipe ne peut en analyser ne règle pas le retard de maintenance.
Conservez les liens vers les notes de version pertinentes dans la demande. Le relecteur doit pouvoir repérer les changements incompatibles, les migrations demandées et les nouvelles conditions de configuration. Ne réduisez pas la revue au passage d’un numéro de version à un autre.
Choisir les tests selon les usages touchés
Repérez les parcours qui utilisent le composant. Une bibliothèque de dates peut affecter une échéance, un export et l’affichage d’un historique. Un outil de génération de documents demande de vérifier le résultat produit, y compris lorsque le processus ne renvoie aucune erreur.
Préparez des exemples stables avec leurs résultats attendus. Pour un document, vérifiez le contenu et les éléments de mise en page nécessaires à son usage. Pour une intégration, testez les erreurs et les réponses inattendues en plus du cas réussi.
Le premier pipeline CI/CD doit rendre ces résultats accessibles à la personne qui valide. Si un contrôle nécessite une comparaison visuelle ou une décision métier, conservez cette étape dans la recette. L’absence d’erreur de compilation ne couvre pas tous les comportements de l’application.
Préparer une livraison identifiable
Installez d’abord la version candidate dans un environnement adapté et notez le résultat construit. Vérifiez que la configuration correspond aux exigences nouvelles. Une mise à jour qui demande une migration de données doit être traitée comme telle, avec ses conséquences de reprise.
Définissez les signaux à surveiller après livraison : erreurs du parcours concerné, échecs de traitement ou retours du support. Prévoyez la personne qui les examine et le moment de cette vérification. Conservez une référence à la version précédente et à ses conditions de réinstallation.
Si la nouvelle version modifie des données, relisez le plan de retour arrière. Réinstaller une bibliothèque précédente peut ne pas suffire à remettre les informations dans leur format antérieur. La décision de reprise doit tenir compte de ce qui a déjà été exécuté.
Garder un registre des exceptions
Lorsqu’une mise à jour est différée, notez la raison, le responsable et la date de réexamen. Précisez la mesure temporaire éventuelle et les conditions qui rendraient la décision caduque. Une dépendance abandonnée ou une migration importante peut nécessiter un chantier séparé.
À la revue suivante, commencez par ces exceptions. Vérifiez que les usages et les contraintes n’ont pas changé, puis clôturez celles qui ont été traitées avec une preuve de livraison. Le registre devient ainsi un suivi de décisions, utilisable lors d’un changement de prestataire.