RÉSOLUTION DE PROBLÈME
Quand tout s’effondre, je reste méthodique. Wireshark, logs, hypothèses jusqu’à isoler la vraie cause.
Définition et contexte
La résolution de problème, ce n’est pas juste « corriger un bug ». C’est une approche systématique pour isoler la vraie cause d’une situation qui ne fonctionne pas. C’est éliminer les variables, tester les hypothèses, et refuser de s’arrêter au premier symptôme.
En entreprise, cette compétence est critique. Un client sans internet n’a pas besoin qu’on raconte la théorie du réseau: il a besoin qu’on trouve le problème en 4h maximum. Un POC qui ralentit n’a pas besoin de jolis commentaires de code : il a besoin qu’on comprenne pourquoi le change détection de Angular consomme 80% du CPU.
Aujourd’hui, la résolution de problème est devenue une compétence très demandée en cybersécurité et infrastructure. Les organisations ne cherchent plus juste des gens qui peuvent installer un firewall : elles cherchent des gens qui savent diagnostiquer pourquoi une architecture faille et proposer des solutions durables. C’est pour ça que j’ai voulu vraiment approfondir cette compétence.
Éléments de preuve : Trois anecdotes qui l'illustrent
L’incident du device malveillant (Zenconnect)
Chez Zenconnect, je gérais 15 à 20 tickets par jour. Un client signale une chute de débit internet inexplicable. Pas de config cassée récemment, juste… ça ralentit.
Beaucoup auraient blâmé le FAI. Moi, j’ai attaqué méthodiquement : Wireshark pour capturer le trafic sur la liaison internet, analyse des trames en détail. Rien d’évident au premier coup d’œil. Mais en creusant, j’ai remarqué des logs Cisco très bizarres sur un VLAN spécifique (trafic chiffré extrêmement lourd, sortant du site).
J’ai remonté les logs Cisco complets pour ce VLAN et là, j’ai vu que quelqu’un s’était loggé avec des credentials légitimes. Mais rien que je ne reconnaisse. Une bonne matinée de dig plus tard : un device physique avait été branché sur un port de switch dans la salle admin (une boîte d’écoute passive du réseau).
Résultat : J’ai isolé la vraie cause (accès physique + credentials compromises + écoute passive), pas juste « le débit baisse ». Le client a pu sécuriser ses ports, changer ses credentials, et mettre en place une politique d’accès physique. [Lire la réalisation complète : Zenconnect]
Le bug de routage au projet ESIEA
Au projet réseau virtualisé, une communication critique ne passait pas entre deux VLANs. Un client du VLAN production ne pouvait pas parler aux serveurs du VLAN serveurs.
Classiquement, c’est un problème de routage ou de firewall qui bloque. Mais lequel ? Où exactement ?
J’ai approché ça systématiquement : vérifier les routes sur pfSense, checker les ACLs ligne par ligne, tracer le trafic avec des pings progressifs pour identifier exactement où ça casse. Pas de random debugging.
Finalement : c’était une route par défaut mal configurée sur pfSense qui causait un blackhole (trou noir) pour ce VLAN spécifique. Les paquets partaient mais ne revenaient jamais.
Résultat : Correction rapide, communication rétablie. Mais surtout, j’ai appris que l’expérience terrain (Zenconnect) permet de raisonner systématiquement sur les problèmes réseau au lieu de crier « c’est cassé ! ». [Lire la réalisation complète : Réseau virtualisé ESIEA]
La vulnérabilité de concurrence BDD (Sopra Steria)
Chez Sopra Steria, durant une analyse de risque, on travaillait sur une base de données critique utilisée par plusieurs services simultanément.
Au lieu de juste cocher « BDD mal configurée » et passer au suivant, j’ai creusé la doc technique (pourquoi le doc existe si personne n’en parle ?). Et j’ai découvert une vulnérabilité de concurrence : si deux processus appelaient la même BDD en même temps et faisaient des modifications simultanées, on pouvait soutirer des infos sensibles, crasher la BDD, ou créer des états incohérents.
Solution : la doc du vendor proposait déjà un système de versioning des données (timestamp + hash pour chaque modif). C’était là, mais personne ne le savait.
Résultat : Implémentation du versioning, audit complet, la BDD sécurisée. [Lire la réalisation complète : Sopra Steria]
Mon autocritique : Où j’en suis vraiment
Je me considère à un niveau confirmé à expert sur cette compétence. J’ai acquis la capacité à rester calme face aux problèmes complexes et à approcher ça méthodiquement. Chez Zenconnect, 15 à 20 tickets par jour, zéro escalade – ça forge cette compétence.
Ma marge de progression : Je sais diagnostiquer des problèmes réseau et système. Mais les problèmes purement architecturaux (pourquoi cette conception entière est fragile ?) sont plus lents à identifier. Je dois développer plus de recul stratégique plutôt que juste du diagnostic tactique.
Contextualisation : Cette compétence ne fonctionne pas pareil en toute situation. En support IT classique (ticket à la fois), tu as le temps de creuser. En incident critique avec une pression client énorme (4h max pour répondre), tu dois être beaucoup plus rapide et décisif. Chez Zenconnect, j’ai appris cette vitesse. Chez Sopra, j’ai appris le recul stratégique.
Vitesse d’acquisition : J’ai acquis cette compétence progressivement et lentement. Chaque incident, chaque bug, chaque problème = une leçon. Y’a pas de raccourci : faut pratiquer.
Mon conseil pour moi-même (et les autres) : Avec l’expérience que j’ai aujourd’hui, je dirais : ne te précipite pas à chercher une solution. Prends 10 minutes pour comprendre le vrai problème d’abord. 80% des gens font l’inverse : ils paniquent et appliquent une solution au hasard. C’est comme ça qu’on crée des pansements au lieu de vrais fixes.
Mon évolution : Où je veux aller
À moyen terme, je veux monter en niveau de recul. Passer de « je diagnostique ce bug réseau » à « je vois que cette architecture entière a un problème de conception ». C’est pour ça que je me spécialise en cybersécurité et audit – c’est une forme plus élevée de résolution de problème.
Formations en cours : Je n’ai pas de formation formelle prévue sur la résolution de problème en soi (c’est une soft skill, ça s’apprend en faisant). Mais je suis les certifications ISO 27001 et 27005 qui vont me donner des frameworks pour diagnostiquer les problèmes de sécurité à l’échelle gouvernance.
Réalisations rattachées:
- Zenconnect (incident device malveillant)
- Sopra Steria (vulnérabilité BDD)
- Réseau virtualisé (bug routing)