Quoi de pire que de ne pas savoir ? Ne pas savoir qu’on ne sait pas !

J’ai toujours aimé comprendre les choses, que ce soit dans mon travail ou dans ma vie privée. Je vous rassure, je ne vais pas vous dresser mon profil psychologique, mais simplement expliquer que connaître les choses en détails permet d’accomplir beaucoup de choses dans un environnement professionnel.

Il y a trois aspects essentiels liés au SAVOIR dans les métiers que j’ai eu l’occasion d’exercer :

1. Comprendre le fonctionnement d’un sujet.
2. Connaître la source et les conditions de collecte des informations.
3. Comprendre le travail des personnes impliquées.

Ces connaissances varient en profondeur en fonction des liens avec ce savoir.

Pour comprendre comment quelque chose fonctionne, prenons l’exemple d’un composant se connectant à un réseau Wi-Fi. Comme nous le savons tous, une connexion Wi-Fi n’est jamais totalement stable, et il peut arriver, pour diverses raisons, que le Wi-Fi ne soit plus utilisable.

La question qui se pose est la suivante : comment gère-t-on cette situation, et quels moyens met-on en place pour récupérer une connexion Wi-Fi fonctionnelle ? Voici quelques scénarios possibles :

1. Gestion via un événement : Dans ce cas, le composant logiciel chargé de gérer l’absence de Wi-Fi se reconnectera dès que possible, en suivant un schéma préétabli. Cela permet d’espérer un temps sans connexion réduit au strict minimum.
2. Gestion par détection périodique : Si la prise en charge se fait par une détection ayant lieu à intervalles réguliers, le temps de résolution dépendra du laps de temps entre la perte du Wi-Fi et le prochain cycle de détection. Ce délai peut influencer la réactivité du système.
3. Aucune mesure spécifique mise en place : Si rien de spécial n’est fait, il faudra probablement attendre un redémarrage du composant pour que le Wi-Fi soit à nouveau disponible.

D’un point de vue logique, on peut considérer que le système dispose d’un mécanisme d’auto-réparation. Cependant, sans entrer dans les détails techniques, on peut déjà observer les différences entre ces trois approches.

La connaissance de la source et des conditions de récolte des informations est essentielle lorsque notre travail repose sur des données collectées par d’autres ou par des systèmes automatisés. Cela détermine les actions à entreprendre pour le traitement des données.

Prenons l’exemple du Wi-Fi qui cesserait de fonctionner sur notre composant. Quelle est la manière dont l’information sur l’état du Wi-Fi est remontée ?

1. Détection humaine : Si la collecte d’informations est effectuée manuellement par un être humain, il est peu probable que cela soit précis. À moins d’avoir un composant critique surveillé en permanence par une personne, chaque panne ne sera pas nécessairement répertoriée.
2. Tentative de connexion externe : Si la collecte se fait via une tentative de connexion depuis un système externe, cela se produira au mieux à intervalles réguliers. De plus, comment différencier un problème d’alimentation, un problème avec le composant lui-même et un problème de Wi-Fi ?
3. Collecte périodique : Si la collecte se fait à intervalles réguliers, il existe un risque que la détection ne soit pas calibrée correctement. Une panne pourrait survenir et se réparer entre deux cycles de détection.
4. Événement de détection : La collecte par événement, c’est-à-dire l’enregistrement immédiat dès qu’un problème survient, est la méthode la plus précise.

En ce qui concerne la remontée de l’information :

5. Envoi direct vers le serveur : L’information sur le problème Wi-Fi est-elle envoyée directement au serveur, avec éventuellement plusieurs tentatives ?
6. Enregistrement local suivi d’envoi : L’idéal serait d’enregistrer localement l’information dès que le problème se produit sur le composant, puis de l’envoyer vers le serveur une fois la connexion rétablie.

Chaque approche a ses avantages et ses inconvénients, et le choix dépendra du contexte spécifique et des exigences du système. 

Un lien très important entre comment ça fonctionne et la récolte des informations

Ce lien entre le fonctionnement du système et la récolte des informations est crucial. Examinons plus en détails les implications de ces deux aspects :

1. Détection par le processus d’auto-réparation : Si le système détecte les problèmes via un processus d’auto-réparation qui s’exécute toutes les minutes, cela peut être acceptable pour certains composants. Une coupure réseau d’une minute n’est peut-être pas problématique dans certains contextes.
2. Détection par le processus de remontée d’informations : En revanche, si la détection se fait uniquement toutes les 5 minutes via un processus de remontée d’information, cela signifie que le problème doit durer au moins 5 minutes pour être détecté. Cela peut poser des problèmes si le souci de Wi-Fi est plus court (par exemple, 30 secondes) mais se produit fréquemment (plus de 1500 fois par jour). Dans ce cas, tu obtiens 45 000 secondes d’indisponibilité sur les 86 400 secondes d’une journée. La détection ne se produira probablement pas au bon moment, et cela peut avoir un impact significatif sur la disponibilité du composant.
3. Réparation vs détection : D’un point de vue fonctionnel, la réparation est souvent plus importante que la détection. Si le système peut réagir rapidement à un problème, même s’il ne le détecte pas immédiatement, cela peut améliorer l’expérience utilisateur. Cependant, il est essentiel de trouver un équilibre entre la fréquence de détection et la réactivité de la réparation.
4. Optimisation : Pour optimiser la situation, il serait judicieux d’ajuster la fréquence de détection en fonction de la fréquence réelle des problèmes. Par exemple, si le Wi-Fi se déconnecte fréquemment pendant de courtes périodes, une détection plus fréquente pourrait être nécessaire. De plus, envisager d’enregistrer localement les informations sur les pannes dès qu’elles se produisent, puis de les envoyer vers le serveur une fois la connexion rétablie est probablement la chose la plus adéquate à faire lorsque c’est possible.

En fin de compte, la conception du système doit tenir compte à la fois du fonctionnement interne et de la collecte d’informations pour garantir une expérience utilisateur optimale. 

Le troisième aspect de savoir comment les personnes travaillent 

Si un composant a un problème de wifi, comment les équipes de terrain vont-elles intervenir ? Dans quelles conditions vont-elles intervenir ?

1. Est-ce qu’on envoie des personnes intervenir sur les problèmes de chaque composant quand un problème se produit ? La qualité des informations est alors primordiale, car si c’est pour envoyer du personnel régulièrement pour vérifier un composant, cela doit se faire uniquement quand c’est pertinent. Et non pas en cas de plainte d’un client, par exemple, sans savoir réellement ce qui se passe. Si le souci affecte le client, c’est un échec.
2. Si une intervention est lancée en fonction des données remontées par l’outil de diagnostic, il faut que celui-ci soit bien calibré et permette de dire de façon la plus précise ce qui se passe, afin que le personnel qui se rend sur place sache ce qu’il doit faire. Vérifier le composant, vérifier la connectivité sur place, lancer une reconfiguration du composant ou prévoir un changement de composant.
3. Si la personne qui intervient arrive sur place et voit que le composant est parfaitement connecté au wifi à ce moment-là, il faut qu’elle sache quoi faire dans ce cas-là. Et pas qu’elle pense qu’il s’agit d’une nouvelle intervention inutile.
4. Qu’importe ce qu’il se passe sur place, il peut être prévu dans les procédures de remplacer quoi qu’il arrive un composant dit défectueux. Cela peut engendrer un grand nombre de remplacements. Si le souci n’est pas lié au composant, mais plutôt à un bug ou à une mauvaise analyse des données, cela va surcharger le service de réparation pour un gain nul.
5. Dans le même ordre d’idées, si on envoie une équipe sur place pour vérifier que tout est fonctionnel et que la conclusion est à chaque fois la même (le wifi est pleinement fonctionnel), il faut des données les plus précises possibles pour savoir quand le souci se produit. Prenons l’exemple d’un souci se produisant en heure de pointe, mais pour lequel les équipes interviennent chaque fois en heure creuse. Les conditions sont potentiellement différentes.

Il faut TOUT savoir

1. Tout savoir pour apporter les bonnes réponses :
   • Comprendre en détails le fonctionnement des composants, des logiciels et des systèmes est crucial. Cela permet de diagnostiquer correctement les problèmes et d’appliquer les solutions appropriées.
   • Par exemple, si un composant présente des dysfonctionnements, il est essentiel de savoir si le problème provient d’un bug logiciel ou d’un défaut matériel. Agir sans cette connaissance peut entraîner des réparations inutiles ou inefficaces.
2. Visibilité et communication :
   • La visibilité des problèmes est également importante. Dans le cas du composant indisponible la moitié du temps, il est crucial de rendre cette information visible pour les personnes en charge du composant ou l’utilisant.
   • Attendre qu’une personne tombe sur le problème par hasard n’est pas une solution efficace. Cela peut entraîner des retards, des insatisfactions des clients et des pertes de productivité.
3. Équilibre entre réactivité et prévention :
   • Trouver le bon équilibre entre réagir rapidement aux problèmes et prévenir les incidents futurs est un défi.
   • Une approche proactive consiste à surveiller les composants, à détecter les anomalies et à mettre en place des mécanismes de récupération automatique. Cela permet de minimiser les temps d’indisponibilité.
   • D’un autre côté, il est essentiel de comprendre les causes profondes des problèmes pour éviter qu’ils ne se reproduisent. Cela nécessite une analyse approfondie et une collaboration entre les équipes techniques.

Tout ce que je décris ci-dessus peut paraître normal une fois qu’on le lit. Toutefois, leurs applications dans la réalité sont parfois fort aléatoires. 

• Est-ce qu’on connaît vraiment les données qui ont permis de générer le dernier graphique présenté lors d’une réunion ? 
• Est-ce qu’on connaît les données qui sont présentes dans le fichier Excel échangé pour justifier un projet ?

Pour conclure, je dirais que ce que je souligne ici n’est pas lié à une éventuelle tromperie ou manipulation qui pourrait être faite. Mais juste un savoir qu’il manque permettant de bien appréhender les choses dans leur ensemble.

Il est essentiel de comprendre que le manque d’informations peut avoir un impact significatif sur notre compréhension globale des situations. Parfois, il suffit d’un petit élément de connaissance pour éclairer davantage notre perspective