Pourquoi cette note ?
J’aime bien reprendre des plateformes que je ne connais pas.
Il y a toujours un petit moment de curiosité.
On ouvre la console. On regarde rapidement les indicateurs principaux. Les agents sont connectés, les composants sont à jour et aucune alerte particulière ne vient immédiatement attirer l’attention.
En quelques minutes, on pourrait presque conclure que tout va bien.
Et pourtant…
C’est souvent à cet instant que mon travail commence réellement.
Pendant longtemps, je me serais probablement arrêté là. Je regardais surtout les versions, les composants et les alertes. J’avais l’impression qu’une plateforme bien maintenue était forcément une plateforme mature.
Avec le recul, je crois que j’avais une vision un peu trop simple.
Le terrain m’a appris que les choses étaient beaucoup plus nuancées.
Le numéro de version indique l’âge du logiciel. Il ne dit rien de l’âge de la manière dont on l’utilise.
Le jour où j’ai commencé à regarder autrement
Aujourd’hui, lorsque je regarde le numéro de version d’une plateforme, j’ai surtout l’impression qu’il répond à une question assez simple.
Quel âge a le logiciel ?
Alors que celle qui m’intéresse vraiment est beaucoup plus difficile à mesurer.
Quel âge a la manière de l’utiliser ?
Je crois que c’est à partir de cette question que j’ai commencé à regarder les plateformes autrement.
Deux entreprises peuvent utiliser exactement le même produit, la même version et les mêmes licences. Elles disposent, sur le papier, des mêmes fonctionnalités.
Pourtant, au bout de quelques années, leurs plateformes peuvent ne plus avoir grand-chose en commun.
L’une continue d’évoluer.
L’autre donne parfois l’impression que le projet s’est arrêté le jour de sa mise en production.
Ce n’est pas une question de compétence.
Encore moins d’implication.
C’est souvent la conséquence naturelle de la vie d’une organisation. Les priorités changent. Les équipes évoluent. Les projets s’enchaînent.
Pendant ce temps, la plateforme continue de fonctionner.
Alors on la laisse vivre.
Retour terrain
Security Platform Engineering • Maturité • Exploitation
Deux plateformes identiques au moment de leur déploiement peuvent devenir très différentes quelques années plus tard.
Le produit évolue de la même manière pour tout le monde. Ce sont les décisions prises autour de lui qui finissent par raconter une autre histoire.
Le déclic
Je me souviens d’une revue de plateforme où tout semblait irréprochable.
Les versions étaient récentes. Les composants étaient en bonne santé. Les tableaux de bord étaient rassurants.
Honnêtement, je m’attendais à une mission assez rapide.
Puis, en discutant avec les équipes, je leur ai posé une question toute simple.
Pourquoi cette fonctionnalité n’est-elle pas utilisée ?
La réponse m’a marqué.
« Parce qu’elle n’existait pas quand on a déployé la plateforme. »
Cette phrase paraît anodine.
Pourtant, elle résume exactement le sujet.
Personne n’avait décidé de ne pas utiliser cette fonctionnalité.
Personne n’y était opposé.
Elle était simplement arrivée après le projet.
Et depuis, plus personne ne s’était réellement reposé la question.
Je retrouve cette situation beaucoup plus souvent qu’on pourrait le croire.
Les plateformes vieillissent rarement d’un seul coup
C’est probablement ce qui rend le phénomène si difficile à percevoir.
Une plateforme ne devient pas ancienne du jour au lendemain.
Elle cesse d’évoluer presque silencieusement.
Une optimisation est repoussée. Une revue attendra le prochain projet. Une nouvelle capacité sera étudiée plus tard.
Une méthode de travail reste en place simplement parce qu’elle fonctionne encore.
Rien de tout cela n’est préoccupant pris séparément.
Mais, mises bout à bout, ces décisions finissent par dessiner une plateforme qui fonctionne toujours parfaitement avec une vision du produit qui appartient parfois à plusieurs années en arrière.
Pendant ce temps, l’éditeur continue d’avancer.
De nouvelles capacités apparaissent. Certains moteurs progressent. Des limites historiques disparaissent. Des processus autrefois complexes deviennent plus simples.
Le produit grandit.
Mais il arrive que notre manière de l’exploiter reste fidèle au premier chapitre.
NOTE TERRAIN
Ce que le terrain m’a appris : une plateforme ne vieillit pas uniquement lorsque son logiciel devient ancien. Elle vieillit aussi lorsque son exploitation cesse d’évoluer.
Ce qui a changé dans ma manière de travailler
Il y a quelques années, une revue de plateforme consistait surtout, pour moi, à vérifier si tout était correctement configuré.
Aujourd’hui, je crois que je passe davantage de temps à comprendre pourquoi la plateforme est configurée ainsi.
Je cherche moins les erreurs.
J’essaie surtout de comprendre les décisions.
Parce qu’une décision qui était excellente il y a cinq ans n’est pas forcément celle que je prendrais aujourd’hui.
Et c’est parfaitement normal.
Le produit a évolué. Les usages aussi. L’organisation n’est plus exactement la même.
Il serait presque étonnant que la plateforme n’ait rien à apprendre de ces changements.
Une plateforme n’est jamais uniquement la photographie d’un produit. Elle est aussi la photographie des décisions prises autour de ce produit.
La question que je me pose désormais
À la fin, il ne me reste presque toujours qu’une seule question.
Si nous devions reconstruire cette plateforme aujourd’hui, est-ce que nous referions les mêmes choix ?
Je trouve cette question beaucoup plus intéressante que :« Sommes-nous sur la dernière version ? »
Parce qu’elle ne cherche pas à juger les décisions passées.
Elle cherche simplement à savoir si elles seraient toujours les mêmes aujourd’hui.
Et la réponse est très souvent non.
Non pas parce que les équipes se sont trompées, mais parce que le produit a évolué.
Les besoins ont évolué.
L’organisation a évolué.
Cette question ne parle finalement plus seulement du logiciel.
Elle parle de notre capacité à continuer d’apprendre.
Conclusion
Je continue à regarder le numéro de version lorsque j’ouvre une plateforme.
Mais je le fais presque par habitude.
Ce qui m’intéresse réellement commence quelques minutes plus tard.
Lorsque j’essaie de comprendre comment cette plateforme a grandi, comment elle s’est adaptée et quels choix ont été faits autour d’elle.
Et surtout, depuis combien de temps certains de ces choix n’ont plus été remis en question.
Au fond, une plateforme ne reflète pas seulement le travail de son éditeur.
Elle reflète aussi la manière dont une organisation apprend, évolue ou, parfois, cesse progressivement de se remettre en question.
C’est précisément ce regard que j’avais envie de partager en ouvrant cette nouvelle série de Notes de terrain consacrée auSecurity Platform Engineering.
Installer une plateforme est un projet. La maintenir est une nécessité. Continuer à la faire évoluer est probablement l’un des plus beaux métiers d’un ingénieur.
POINT D’ATTENTION
Cette Note de terrain est inspirée de situations rencontrées au cours de différentes missions. Les exemples présentés ont été volontairement anonymisés et généralisés afin de préserver la confidentialité des organisations concernées.