Au-delà des silos : l’âme derrière OSIRIS JSON
Depuis vingt ans, ma mission est de combler le fossé entre la connaissance tribale cloisonnée dans des silos et la clarté opérationnelle. J’ai évolué depuis l’ère manuelle, faite de cartographie minutieuse de topologies fragmentées, jusqu’à la création d’une solution qui fournit un instantané complet, de bout en bout, du paysage d’infrastructure. Mon objectif en construisant OSIRIS JSON est simple : offrir une visibilité d’ensemble qui permette aux professionnels IT et OT de prendre les bonnes décisions en toute confiance.
Dans le monde des infrastructures, nous nous contentons souvent de fragments. Nous voyons un serveur ici, une instance cloud là, un capteur de facility ailleurs. Mais mon objectif, peu importe avec qui et pour qui j’ai travaillé, a toujours été d’obtenir une vision de bout en bout de l’infrastructure entière, en voyant comment chaque élément respire ensemble dans une seule carte interconnectée, pour une raison très simple : atteindre plusieurs objectifs :
- éradiquer les silos, la pensée féodale et le contexte critique conservé dans la tête des personnes en adoptant une culture Documentation as Code (Docs as Code) fondée sur des standards ouverts
- offrir un moyen simple aux architectes et aux professionnels IT/OT de comprendre l’infrastructure de bout en bout dans un état à jour à un instant donné
- permettre un dépannage rapide en maintenant une documentation et une topologie d’infrastructure claires et à jour
- permettre un instantané rapide, de bout en bout, de l’infrastructure sans complications ni logiciels de scan tiers, faisant d’OSIRIS JSON un grand allié lors des sessions d’audit
- fournir une base standardisée et précise pour les LLM, leur permettant de comprendre le paysage d’infrastructure et d’apporter un raisonnement et une automatisation améliorés
Le côté humain de la lutte dans les infrastructures
En décembre 2025, avec une grande ambition et un brin de folie, j’ai commencé à rédiger la Spécification OSIRIS JSON. Elle est le résultat de l’expérience acquise en voyageant, en explorant, en échangeant avec des Senior Managers et des professionnels IT/OT, mais aussi en me rapprochant et en travaillant avec des ouvriers d’usine et leurs responsables, avec lesquels j’ai eu une formidable opportunité d’apprendre dans des contextes différents qui ont représenté pour moi un enrichissement personnel et ont aidé à façonner l’idée originale, en ayant la possibilité de voir et de comprendre que ce type d’organisation et de visibilité manquait non seulement dans le domaine de l’Information Technology, mais aussi du côté OT dans les systèmes de facility ou dans des scénarios transversaux, et même dans la conception, la maintenance et parfois l’échec au sein de stacks hétérogènes, depuis les clouds publics hyperscale jusqu’aux intersections complexes et rugueuses entre IT et Facility OT.
Tout au long de ce parcours, j’ai rencontré un problème récurrent et profondément humain : l’infranchissable montagne de la connaissance tribale. Certaines phrases que nous avons tous entendues : Oh ne touchez pas à ça s’il vous plaît, nous savons que c’est obsolète mais c’est Charles qui l’a fait et il a quitté l’entreprise ! La documentation n’est pas importante, concentrons-nous sur les besoins métier ou la fausse croyance que tout va bien Tous les services sont parfaitement configurés dans Microsoft Azure, il n’y a rien à craindre. Ou bien vous êtes convoqué à une réunion d’approbation ARM ou SBB et quelqu’un trace quelques lignes dans Microsoft Paint pour représenter la topologie en cherchant une approbation immédiate parce que les parties prenantes sont pressées ! Quelques semaines plus tard, lorsque vous êtes appelé pour analyser avec les operations une panne majeure, vous découvrez que quelqu’un a mal configuré quelque chose dans l’architecture du système et vous ne savez pas par où commencer le troubleshooting, car il n’existe ni documentation ni topologie précise. Nous avons tous eu ou avons encore un Charles dans l’organisation.
Nous luttons contre des silos d’entreprise qui rendent une vue unifiée presque impossible ! Nous construisons des intégrations sur mesure et fragiles qui cassent dès qu’un fournisseur change d’avis, et nous savons que cela arrive régulièrement, en particulier dans l’IT.
Même dans les scénarios où j’ai produit une documentation rigoureuse, la présence de silos entre équipes signifiait souvent que la “vérité” de l’infrastructure restait cachée ou fragmentée. J’ai compris que si nous ne pouvons pas voir notre monde, nous ne pouvons pas vraiment en prendre soin en prenant les bonnes décisions avec confiance.
Je crois fermement que la clarté de l’infrastructure des systèmes NE DOIT PAS dépendre de qui vous êtes, de qui vous connaissez ou du département auquel vous appartenez. Elle est et DOIT être une vérité partagée qui appartient à tout le monde. - Tia Zanella - Founder and Lead Maintainer of OSIRIS JSON
Qu’est-ce qu’OSIRIS JSON ?
OSIRIS JSON est un schéma d’échange JSON vendor-neutral conçu pour être un langage universel pour la topologie d’infrastructure, pensé pour inclure les environnements IT et OT.
Plutôt que de perdre du temps et de l’argent à développer chaque intégration logicielle depuis zéro pour apprendre une centaine de dialectes spécifiques aux fournisseurs, OSIRIS JSON sépare les responsabilités :
- Les producteurs OSIRIS JSON traduisent les données désordonnées et fragmentées du monde réel en un document OSIRIS JSON propre.
- Les consommateurs OSIRIS JSON lisent ce document afin de fournir une vue claire, à un instant précis, de ce qui existe et de la manière dont tout est relié. Avec le document OSIRIS JSON, les consommateurs peuvent produire des topologies, des diff, une documentation automatisée de haute qualité, et plus encore.
Un premier pas humble
Dans cette première version, OSIRIS JSON est intentionnellement un format d’instantané statique. C’est un “polaroid numérique” de votre infrastructure à un instant donné. Vous pouvez l’exécuter directement depuis votre notebook ou, dans des scénarios complexes, le confier à une automatisation pour produire des résultats planifiés. Il n’essaie pas de tout faire d’un seul coup, mais il fournit quelque chose d’essentiel : une base cohérente. En définissant comment les ressources et leurs relations sont documentées indépendamment des frontières entre équipes ou du vendor lock-in. Dans une culture de communauté ouverte, nous faisons le premier pas vers ce rêve de bout en bout.
OSIRIS JSON est plus que du code ; c’est un engagement persévérant envers la transparence, une documentation de haute qualité et la conviction profonde que même les systèmes les plus complexes peuvent être compris si nous portons les bonnes lunettes.