J’étais sur le terrain quand Brussels Airport a été attaqué.
Pas dans un rapport de conférence. Dans la salle des serveurs, un vendredi soir de septembre 2025.
Section 1 – Le récit
15 septembre 2025. Brussels Airport, Zaventem. Jour 1 de ma mission.
Je n’ai même pas eu le temps de poser mes affaires. Une cyberattaque venait de paralyser les systèmes de plusieurs aéroports européens. Sur le terrain, ça donnait ça : les agents de ticketing debout devant des passagers qui attendaient depuis des jours, un enregistrement, un check-in, une pesée de bagages qu’il fallait refaire à la main, comme si les vingt dernières années d’informatisation n’avaient jamais existé.
Sur l’action de terrain – déploiement, assistance directe, guide des agents à leurs postes – on était deux : un apprenti et moi. Une équipe distante restait en soutien en cas de besoin, mais l’essentiel de ce qui s’est joué ces nuits-là, c’est nous deux, poste par poste.
Il a fallu déployer plus de 30 machines en urgence – des postes propres, jamais connectés au réseau compromis. Mettre en place un accès VPN pour 50 à 80 personnes en simultané, sur des shifts décalés qui ne s’arrêtaient jamais vraiment. Deux semaines plus tard, la situation était stabilisée.
Je suis, à ma connaissance, le seul de ma zone à l’avoir vécu directement sur le terrain.
Ce que douze ans de métier m’ont appris avant cette nuit-là
Cet épisode n’a rien d’un coup de chance improvisé. Il s’appuie sur douze ans passés dans des environnements où l’erreur ne pardonne pas : datacenters, support applicatif critique, ITSM, IT Ops. Des missions qui m’ont emmené à l’autre bout du monde travailler sur site avec des équipes locales, et d’autres où j’ai piloté des interventions depuis mon bureau en Belgique, coordonné avec des collègues et des partenaires à des milliers de kilomètres, fuseaux horaires décalés compris.
C’est cette double expérience – la capacité à être seul devant l’urgence, et celle à orchestrer à distance avec des équipes qu’on ne voit jamais physiquement – qui fait la différence quand tout s’arrête en même temps. Structurer, prioriser, faire avec ce qu’on a sous la main : c’est un réflexe qui se construit sur des années, pas sur une nuit.
Ce que cet épisode confirme, pour vous
La différence entre une entreprise qui encaisse une cyberattaque et une entreprise qui s’effondre ne se joue pas le jour de l’attaque. Elle se joue dans les mois qui précèdent – dans la cartographie des actifs qu’on n’a jamais faite, dans les accès qu’on n’a jamais révoqués, dans l’audit qu’on a toujours reporté.
Si ça vous arrivait demain, votre entreprise tiendrait combien de temps ?
Section 2 – La posture 1LoD
1LoD – First Line of Defense. Ce n’est pas un acronyme marketing, c’est une discipline.
Dans les environnements régulés à haute disponibilité, la première ligne de défense n’est pas un firewall. C’est la structuration opérationnelle : qui a accès à quoi, qui valide un changement avant qu’il parte en production, qui documente un incident pour qu’il ne se reproduise pas.
La majorité des PME belges n’ont personne occupant cette fonction. Pas par négligence – parce que ce poste n’existe structurellement pas dans une entreprise de 80 employés. C’est exactement l’espace que Phoenix Tech MSP occupe.
Concrètement, ça donne :
- Une gouvernance IT calquée sur les standards ITIL 4, adaptée à votre taille – pas un cadre théorique copié d’un grand groupe
- Une méthode d’audit qui produit un livrable opposable, pas une liste de recommandations vagues
- Une gestion des incidents structurée autour du RCA (Root Cause Analysis) – on comprend pourquoi, pas seulement on répare
Section 3 – Ce que je constate, et ce que j’en fais
Dans la quasi-totalité des PME belges de 50 à 250 employés que je croise, le constat est le même : l’IT tourne, personne ne se plaint au quotidien, et pourtant personne ne pourrait dire avec certitude qui a accès à quoi, ni ce qui se passerait vraiment en cas d’incident sérieux. Ce n’est pas de l’incompétence. C’est simplement qu’à cette taille d’entreprise, personne n’a le rôle, le temps, ni le mandat pour s’en occuper sérieusement.
Le problème n’est plus seulement interne. Vos clients, vos assureurs, vos donneurs d’ordres commencent à poser des questions précises sur votre sécurité et votre conformité NIS2. Une bonne intention ne suffit plus comme réponse – il faut un document.
Ma façon d’y répondre est simple : je prends le temps de cartographier ce qui existe réellement (pas ce que tout le monde suppose), je referme les portes ouvertes qui comptent le plus, et je vous laisse un document que vous pouvez montrer, pas une explication orale qui s’oublie en sortant de la réunion.
Je ne viens pas vendre du volume d’heures ou un contrat qu’on renouvelle par habitude. Je viens structurer ce qui doit l’être, avec un objectif clair et une fin définie – et si vous voulez continuer ensuite, ce sera parce que ça a servi, pas parce que le contrat vous y oblige.
Section 4 – Pourquoi Phoenix Tech MSP et pas un autre prestataire
| Prestataires généralistes | Phoenix Tech MSP | |
|---|---|---|
| Tarification | Sur devis, jamais affichée | Prix fixe, affiché |
| Expérience critique | Références clients standards | Cyberattaque aéroportuaire réelle, vérifiable |
| Spécialisation | Multi-sectorielle diluée | Logistique, industrie, santé – NIS2/DORA |
| Posture | Support technique | Gouvernance 1LoD, niveau direction |
| Livrable | Rapport d’intervention | Document opposable pour assureurs/auditeurs |
Une conversation de 30 minutes, sans engagement, pour évaluer où vous en êtes réellement.