La première fois qu'on connecte SentraFlow à un SI d'entreprise, le résultat n'est jamais ce que les équipes anticipaient. Pas parce que le système est particulièrement complexe, mais parce qu'il y a toujours un écart entre ce que les gens pensent que leur architecture ressemble et ce qu'elle est réellement. Cet écart est presque universel, et c'est précisément ce qui rend la cartographie utile.
Le service que personne ne veut toucher
Dans presque chaque SI qu'on analyse, il y a au moins un service que tout le monde connaît mais que personne ne veut modifier. Il tourne, il fait son travail, et ça s'arrête là. La documentation date d'il y a plusieurs années. L'équipe qui l'a construit n'est plus là. Personne ne sait exactement ce qui en dépend. Ce service n'est pas un problème en soi. Il devient un problème le jour où une migration ou une modernisation voisine le touche sans le savoir.
Ce qu'on observe
La cartographie automatisée révèle régulièrement des dépendances vers ces services fantômes que les équipes n'avaient pas documentées, et parfois ne soupçonnaient pas.
La documentation est toujours en retard
Ce n'est pas un reproche aux équipes, c'est une réalité structurelle. Un SI évolue en continu. Les équipes livrent, les configurations changent, des services s'ajoutent. La documentation, elle, est mise à jour lors des grands projets, rarement entre les deux. Résultat : la carte mentale que chaque développeur porte en tête correspond à l'architecture d'il y a six mois, pas à celle d'aujourd'hui. Multiplié par dix équipes, c'est dix versions légèrement différentes du même SI qui coexistent dans les têtes.
Le shadow IT est là, dans les logs
L'un des patterns qu'on rencontre le plus souvent : des flux entre services qui n'apparaissent dans aucun schéma d'architecture, mais qui sont bien visibles dans les logs et les traces réseau. Ce n'est pas forcément du shadow IT au sens malveillant. C'est souvent le résultat d'un contournement pragmatique : une équipe qui a trouvé un raccourci pour résoudre un problème, sans que ça soit formalisé. Ces connexions informelles sont les premières à créer des incidents lors d'une migration.
Pourquoi un diagramme statique ne suffit pas
Un diagramme d'architecture fait à la main représente le SI tel qu'il était au moment où on l'a dessiné. Une cartographie vivante, alimentée en continu par l'analyse réelle du système, représente le SI tel qu'il est aujourd'hui. La différence n'est pas technique, elle est stratégique : les décisions de transformation prises sur la base d'une carte à jour ont un tout autre niveau de fiabilité que celles prises sur une présentation PowerPoint mise à jour la dernière fois lors d'un audit.
La cartographie comme point de départ, pas comme fin en soi
Ce qu'on observe chez les équipes qui utilisent SentraFlow sur le long terme, c'est que la carte n'est pas une livrable, c'est un outil de travail quotidien. Elle sert à préparer une migration, à onboarder un nouveau prestataire, à répondre à une question d'audit, à prioriser les efforts de modernisation. La valeur ne vient pas de l'existence de la carte, mais de la confiance qu'on peut y accorder parce qu'elle est maintenue automatiquement.