Instruire l'ajout d'une dépendance extérieure

Quand l’employer

À employer avant d'accepter qu'un agent ajoute une bibliothèque, un service payant ou un fournisseur tiers. À ne pas employer après coup : une dépendance installée se retire difficilement.

Les 4 trous à remplir avant d’envoyer

Chaque trou est une décision déjà prise. Un trou que vous ne savez pas remplir n’est pas une case à improviser : c’est un travail de cadrage qui manque.

{BESOIN_A_COUVRIR}

Quel besoin précis cette dépendance couvrirait-elle, en une phrase ?

Pourquoi ce trou existe. Une dépendance ajoutée pour un besoin flou couvre en réalité dix besoins dont neuf ne vous concernent pas, et vous en portez la charge.

Si vous ne savez pas répondre. Écrivez ce que vous devriez construire vous-même si la dépendance n'existait pas. Si vous ne pouvez pas le décrire, le besoin n'est pas identifié.

{DEPENDANCE_PROPOSEE}

Quelle dépendance l'agent propose-t-il, et par quel chemin est-elle arrivée dans la conversation ?

Pourquoi ce trou existe. Une dépendance introduite au détour d'une réponse, sans avoir été demandée, est le mode d'entrée le plus fréquent des dettes techniques durables.

Si vous ne savez pas répondre. Relisez l'échange et trouvez la première mention. Si elle vient de l'agent et non de vous, exigez la justification avant toute installation.

{DONNEES_QUI_SORTENT}

Quelles données quitteraient votre système pour aller chez ce tiers ?

Pourquoi ce trou existe. Une dépendance qui reçoit des données personnelles engage votre responsabilité, et cette responsabilité ne se délègue pas au fournisseur.

Si vous ne savez pas répondre. Considérez que tout ce qui transite finira dans les journaux du tiers. Si cette phrase vous inquiète, vous avez votre réponse.

{CE_QUI_SE_PASSE_SI_ELLE_TOMBE}

Que devient votre produit si cette dépendance devient indisponible, payante ou fermée ?

Pourquoi ce trou existe. Une dépendance sans plan de sortie devient une décision définitive prise en trente secondes.

Si vous ne savez pas répondre. Décidez, avant l'installation, si le produit doit continuer de fonctionner sans elle. Cette réponse commande tout le reste.

Le corps du gabarit

Quatre parties, toujours dans cet ordre : le rôle et le mandat, le contexte factuel, la demande bornée, le format de sortie exigé. Les trous restent visibles à la copie, et c’est voulu : les remplir un par un est la dernière occasion de s’apercevoir qu’une décision manque.

## 1. RÔLE ET MANDAT

Tu es architecte logiciel. Ton mandat est d'instruire une décision d'engagement durable, pas de la prendre. Une dépendance n'est pas un détail d'implémentation : c'est un engagement que je devrai tenir, payer et exploiter longtemps après ton intervention. Tu ne l'installes pas et tu n'écris aucun code.

## 2. CONTEXTE FACTUEL

Besoin à couvrir : {BESOIN_A_COUVRIR}
Dépendance proposée et origine de la proposition : {DEPENDANCE_PROPOSEE}
Données qui sortiraient de mon système : {DONNEES_QUI_SORTENT}
Ce qui doit se passer si elle devient indisponible : {CE_QUI_SE_PASSE_SI_ELLE_TOMBE}

Je ne demande pas si la dépendance est bonne. Je demande ce qu'elle m'engage à faire, à payer et à surveiller.

## 3. DEMANDE BORNÉE

Instruis l'engagement.

Ce que je veux :
1. ce que la dépendance fait exactement pour mon besoin, et ce qu'elle apporte en plus dont je n'ai pas l'usage ;
2. ce qu'il faudrait écrire moi-même pour couvrir le seul besoin nommé, en volume de travail comparé ;
3. ce que la dépendance exige en retour : compte à créer, clé à conserver, coût, mise à jour, dépendances qu'elle amène avec elle ;
4. le chemin des données vers le tiers, énuméré, et ce qui reste chez moi ;
5. le plan de sortie : par quoi la remplacer, et ce qu'il faudrait réécrire le jour où il faut partir ;
6. la version exacte considérée, et la date à laquelle cette information a été établie.

Ce que je ne veux pas : une installation, une commande à exécuter, une comparaison avec des dépendances concurrentes, un argument fondé sur le nombre d'utilisateurs.

## 4. FORMAT DE SORTIE EXIGÉ

Six sections titrées comme ci-dessus. Toute affirmation sur la dépendance qui ne peut pas être vérifiée dans sa documentation est marquée « non vérifié » en début de ligne. Le plan de sortie est écrit même si tu le juges improbable.

Ta réponse est refusable si elle contient une commande d'installation, si le plan de sortie manque, ou si une affirmation invérifiable n'est pas marquée « non vérifié ».

Ce que vous devez recevoir

• Ce que la dépendance couvre du besoin nommé, et ce qu'elle apporte en trop.
• Le volume de travail comparé entre l'utiliser et écrire soi-même le strict nécessaire.
• La liste des obligations induites : compte, clé, coût, mises à jour, dépendances amenées.
• Le chemin des données vers le tiers, et ce qui reste chez vous.
• Un plan de sortie écrit, même jugé improbable.
• La version exacte considérée et la date de l'établissement de l'information.

Ce qui doit vous faire refuser

Ces motifs sont écrits comme des constats : « un fichier hors périmètre a été modifié » se vérifie, « le travail manque de rigueur » ne se vérifie pas.

• La réponse contient une commande d'installation, ce qui transforme une instruction en acte.
• Le plan de sortie est absent ou remplacé par la mention qu'il ne sera pas nécessaire.
• Les données qui sortent ne sont pas énumérées, ou sont qualifiées d'anonymes sans démonstration.
• Une affirmation invérifiable est présentée comme un fait au lieu de porter « non vérifié ».
• La dépendance amène ses propres dépendances et celles-ci ne sont pas listées.
• L'argument principal est le nombre d'utilisateurs de la dépendance.

Selon pour qui vous construisez

Pour mon employeur.

Une dépendance qui reçoit des données de l'organisation passe par la personne responsable de la conformité avant installation, pas après.

Pour un client.

Toute dépendance payante est portée à la connaissance du client par écrit, avec son coût récurrent. Une facture découverte plus tard se paie deux fois : en argent et en confiance.