Gestion des risques et dépendances logicielles

Faut-il une abstraction pour encapsuler les dépendances externes que l'on intègre dans le code métier ?

La question semble faire débat. ⚖️
Pour moi, la réponse est pourtant simple : parfois oui ✅, parfois non ❌.

En fait, ça dépend du contexte car il détermine l'élément trop souvent oublié : la gestion des risques.

Ne pas encapsuler par peur de rajouter une couche d'abstraction inutile ? Oui, c'est un argument valide.
Encapsuler pour se prémunir d'une éventuelle obsolescence de la dépendance ? Oui, c'est aussi un argument valide.

Comment on décide ?
De manière très simplifiée, on peut utiliser une matrice de criticité.

On se pose 2 questions :

1. 📊 Quelle est la probabilité que l'utilisation de notre dépendance pose un problème dans le futur ?

• Est-elle bien maintenue ?
• A-t-elle beaucoup d'utilisateurs ?
• Une mise à jour ou une absence de mise à jour pourrait-elle poser des problèmes de sécurité ?
• etc.

2. 💥 Quel est l'impact du problème potentiel que cette dépendance pourrait poser ?

• Est-ce que notre système devient entièrement inutilisable ?
• Est-ce qu'on n'aura qu'un désagrément cosmétique ?
• Pourrait-on avoir à indemniser des clients ?
• etc.

Avec la réponse à ces deux questions, la matrice nous donne une criticité.
En fait, il faut se poser ces questions pour chaque facteur de risque que l'on décide de prendre en compte mais prenons un exemple.

Imaginons que l'on utilise une bibliothèque externe de gestion des dates/heures/fuseaux horaires.
Cette bibliothèque n'est plus que maintenue épisodiquement au point de rendre son obsolescence probable pour les évolutions obligatoires de fuseaux horaires ou de changements d'heure été/hiver.

Si, nous utilisons cette bibliothèque dans notre système de réservation de billets de transport, on imagine la vente de billets pour des horaires fantaisistes et un impact financier maximal. On optera dans ce cas pour une criticité maximale.
A l'opposé, si notre système gère des arbres généalogiques avec des dates dans le passé, on aura un impact nul et une criticité très faible.

Dans le cas où la criticité est très faible, on ne va sans doute pas se poser plus de questions : on va utiliser la bibliothèque telle quelle. Ça ne sert à rien de l'encapsuler.

Dans le cas où la criticité est maximale, on devra au moins se poser la question. Soit on accepte le risque en l'état, on ne fait rien de particulier. Qui vivra verra. Soit on décide d'atténuer le risque. En bon franglais, on dit "mitiger" le risque. Et on procède à une action préventive 🛡️ :

• encapsulation de la bibliothèque pour la remplacer s'il y en a un jour besoin
• contribution à la maintenance de la bibliothèque
• etc.

Voilà. La prochaine fois que quelqu'un vous propose son opinion sur la nécessité d'encapsuler ou pas une dépendance, vous pourrez lui demander s'il a des données qui justifient ce choix. 🤷‍♀️