La maintenance des dépendances consiste à connaître les bibliothèques utilisées, évaluer leurs changements et mettre à jour sans casser les parcours métier.
Une dépendance peut corriger une faille, modifier un comportement ou abandonner une version. L’équipe doit savoir où elle est utilisée et comment tester son remplacement. Un fichier de versions seul ne décrit pas le risque.
Inventorier
Conservez les dépendances directes, leurs versions et leur rôle. Identifiez les dépendances transitives et les services externes. Une bibliothèque qui gère les fichiers, les droits ou les montants mérite une attention particulière.
Lire les changements
Avant une mise à jour, lisez les notes de version et vérifiez les changements incompatibles. Testez l’installation propre, le démarrage, les parcours sensibles et les exports. Les tests de contrat API sont utiles lorsqu’un fournisseur externe change.
Déployer progressivement
Mettez à jour une version contrôlée, observez les erreurs et préparez un retour. Une modification de dépendance peut changer la génération d’un PDF ou l’ordre d’un résultat sans provoquer une erreur immédiate. Conservez un échantillon attendu pour comparer.
Les dépendances inutilisées doivent être retirées après vérification. Une réduction de surface simplifie les mises à jour et les contrôles. Le dossier de maintenance doit indiquer les propriétaires et la fréquence de revue.
Sources : OWASP, gestion des dépendances, npm, audit.
Conservez aussi la procédure de retrait d’une dépendance. Identifiez les imports, les configurations, les tests et les scripts qui l’utilisent. Une suppression doit être suivie d’une compilation propre et d’un contrôle de l’image déployée. Cette étape évite de garder un composant uniquement parce que personne n’ose vérifier s’il est encore nécessaire.
Une revue régulière du registre permet de repérer les versions abandonnées et les composants sans propriétaire. Attribuez une date de prochaine vérification à chaque dépendance sensible et conservez le résultat avec la version livrée.
Classer les risques
Une dépendance qui traite des droits, des fichiers, des montants ou des signatures mérite une revue plus stricte qu’un outil utilisé seulement lors de la compilation. Notez le rôle, la version et la conséquence d’une incompatibilité. Un registre simple permet de retrouver le propriétaire avant une mise à jour urgente.
Les dépendances transitives peuvent changer sans modification directe du code. Verrouillez les versions installées et examinez les changements proposés avant de les accepter. Une mise à jour automatique doit produire une demande de revue, des tests et un résultat lisible.
Vérifier les licences
Le registre doit indiquer la licence de chaque composant et les obligations qui s’y rattachent. Une dépendance peut être techniquement sûre mais incompatible avec la distribution prévue du logiciel. Le responsable du produit et l’équipe juridique définissent le traitement des cas incertains.
Conservez les avis de licence avec la version livrée. Une mise à jour peut modifier une obligation ou ajouter un composant. Ne copiez pas un texte sans vérifier qu’il correspond à la version réellement distribuée.
Organiser une mise à jour
Préparez une branche ou un environnement de test. Installez la nouvelle version, exécutez les tests, puis rejouez les parcours de fichiers, d’authentification, d’exports et de calculs. Comparez un échantillon de résultats avec la version précédente.
Une dépendance peut modifier un message d’erreur ou un format sans faire échouer le démarrage. Les tests de contrat et les tests visuels peuvent révéler ces changements. Le plan de retour arrière doit couvrir les données produites par la nouvelle version.
Gérer une vulnérabilité
Lorsqu’une faille est annoncée, identifiez les versions touchées et la présence réelle du composant. Décidez si une mise à jour, une configuration ou une désactivation temporaire réduit le risque. Documentez l’échéance, le propriétaire et la preuve de correction.
Après la mise à jour, recherchez les anciennes copies dans les images, caches et environnements secondaires. Une correction en production ne suffit pas si un traitement différé utilise encore l’ancien paquet. Le registre doit être mis à jour avec la version déployée.
Contrôler les versions déployées
Une image construite hier peut contenir une version différente de celle déclarée dans le dépôt. Conservez l’empreinte de l’image et la liste des paquets effectivement installés. Le support doit pouvoir relier une erreur à cette version sans demander une reproduction immédiate.
Les environnements de travail, de recette et de production doivent suivre une stratégie connue. Une exception temporaire doit avoir une raison et une échéance. Les paquets ajoutés uniquement pour un test doivent être retirés avant la mise en service.
Tester les fonctions sensibles
Après une mise à jour, rejouez les parcours d’authentification, d’upload, de recherche, de calcul et d’export. Comparez les erreurs, les formats et les temps de réponse. Une bibliothèque peut modifier un encodage ou un ordre de tri sans provoquer d’exception.
Documentez le résultat et les limites de la vérification. Si un fournisseur externe n’est pas disponible en recette, utilisez un simulateur et planifiez un contrôle après déploiement. La décision d’accepter le risque appartient au propriétaire du parcours.