Difficultés rencontrées et solutions apportées

Trois blocages du stage, choisis parce qu'ils m'ont chacun coûté du temps et appris quelque chose de transposable. Les deux premiers portent sur des outils ; le troisième sur ma façon de chercher.

Le certificat qui ne sortait jamais

Objectif : obtenir un vrai certificat TLS pour un service hébergé sur un serveur qui n'est pas joignable depuis Internet. La validation habituelle est donc exclue - elle suppose qu'une autorité extérieure vienne lire un fichier sur le serveur. La solution passe par une validation qui repose sur le DNS : on publie un enregistrement, l'autorité le lit, et le serveur n'a jamais besoin d'être atteignable.

Sur le papier, c'est réglé. En pratique, la demande échouait systématiquement avec un dépassement de délai sur le port 53. Le blocage a duré parce que je cherchais l'erreur du mauvais côté : je vérifiais que l'enregistrement était bien créé - il l'était.

La cause était ailleurs. Avant de solliciter l'autorité, l'outil vérifiait lui-même son propre travail en interrogeant directement les serveurs DNS. Or les requêtes DNS sortantes étaient bloquées sur ce réseau. Le contrôle échouait, et l'outil abandonnait avant même de demander le certificat. Il a suffi de désactiver cette auto-vérification pour que tout passe.

Ce n'était pas la tâche qui échouait, c'était le contrôle de la tâche. Depuis, quand un outil échoue sur une étape que je crois maîtriser, je vérifie d'abord ce qu'il vérifie, lui.

Quand l'image ne suit pas la convention

Deuxième blocage, sur la gestion des mots de passe. La bonne pratique consiste à ne plus les passer en variables d'environnement - où ils restent lisibles par quiconque peut inspecter le conteneur - mais à les faire lire depuis un fichier. La plupart des images officielles supportent cette convention. Celle que j'utilisais, non.

Solution : construire une image dérivée avec un point d'entrée qui lit le fichier et le met à disposition de l'application avant de lui rendre la main. Le secret disparaît alors de l'inspection du conteneur, ce que j'ai vérifié plutôt que supposé.

Sauf que l'application refusait toujours de démarrer, en annonçant une configuration incomplète, alors que le secret était bien chargé - les journaux le confirmaient. J'ai fini par ouvrir le script d'installation à l'intérieur de l'image officielle : il exigeait cinq variables, pas quatre. Il en manquait une, sans aucun rapport avec les mots de passe. Lire le code de l'outil qu'on utilise reste souvent plus rapide que deviner son comportement.

Un faux problème d'authentification

Le cas qui m'a le plus appris est celui où le message d'erreur désignait le mauvais coupable. Un outil d'analyse intégré au pipeline échouait invariablement sur « clé d'API invalide ». J'ai d'abord suspecté la clé elle-même, puis la région du compte, puis les droits d'accès.

La bonne décision a été de tester la couche la plus basse en premier : appeler l'API directement, hors du pipeline, avec la clé brute. Réponse au premier essai : invalide. Deuxième essai en copiant la clé au lieu de la retaper : valide. J'avais confondu un I majuscule et un l minuscule, indiscernables dans la police du terminal.

La clé étant confirmée bonne, le problème ne pouvait plus venir que de sa transmission. Il venait d'une ligne de configuration ajoutée lors d'une itération précédente, qui redéclarait la variable en la faisant se référencer elle-même. Le pipeline recevait le nom de la variable au lieu de sa valeur. Aucun message n'y faisait allusion.

Deux enseignements que j'applique maintenant par réflexe : tester la couche la plus basse avant de suspecter la configuration, et se méfier d'un message d'erreur qui désigne un coupable évident. « Clé invalide » ne voulait pas dire que la clé était mauvaise, mais qu'elle n'arrivait pas.

La méthode retenue

• Reproduire le problème avant de le corriger - jamais de correction à l'aveugle.
• Chercher la cause racine, pas le symptôme (les logs d'abord, les hypothèses ensuite).
• Documenter la solution : le prochain bloqué sera peut-être moi, dans six mois.
• Demander de l'aide après avoir cherché - avec un résumé clair de ce qui a déjà été tenté.

Ces situations ont structuré ma façon de travailler : reproduire, corriger la cause, documenter - avant de passer à la tâche suivante.