Un système data peut afficher une stabilité apparente pendant des années et générer des incidents dès qu’un projet d’évolution démarre. Cette situation conduit spontanément à attribuer les dysfonctionnements au changement en cours. Une autre lecture reste cependant possible : le projet ne crée pas nécessairement les fragilités observées, il les rend visibles.
Sommaire
- Quand les incidents surgissent au moment du changement
- Pourquoi un système peut paraître stable tant qu’il n’évolue pas
- Les fragilités exposées par les transformations
- Identifier les causes structurelles par étapes
Quand les incidents surgissent au moment du changement
Les projets de migration, de refonte ou d’ajout d’outils génèrent régulièrement des dysfonctionnements imprévus. Par exemple, un flux d’intégration se met à générer des anomalies lors du passage à une nouvelle version d’ERP. Autre cas fréquent : une Data Platform Analytics fraîchement déployée révèle des incohérences entre plusieurs bases de données à consolider. De même, la mise en place d’un nouveau dispositif de chiffrement, de pseudonymisation ou de contrôle d’accès peut perturber des flux existants, en empêchant certains traitements de retrouver les données nécessaires ou en provoquant des erreurs dans des applications aval.
Ces incidents surviennent alors que le système fonctionnait sans accroc avant le démarrage du projet. Face à cette situation, les équipes constatent une dégradation de la fiabilité pendant la phase de changement et attribuent naturellement ces problèmes au projet en cours. Le diagnostic spontané désigne ainsi la migration comme responsable, l’ajout d’outil comme facteur de risque, la modification comme source d’instabilité.
La chronologie des faits oriente naturellement l’analyse : le système semblait stable avant l’intervention, puis les incidents apparaissent au moment du projet. Cette corrélation temporelle ne permet toutefois pas, à elle seule, de conclure que le changement constitue la cause première. Elle peut aussi signaler que le projet met sous tension des fragilités antérieures et les rend enfin visibles.
Pourquoi un système peut paraître stable tant qu’il n’évolue pas
Un système data affiche une stabilité apparente lorsque les flux empruntent toujours les mêmes chemins, les traitements mobilisent les mêmes ressources et les dépendances entre composants restent sollicitées de manière identique. L’architecture supporte cette charge répétitive sans défaillance.
Or, tout projet d’évolution du SI modifie ces conditions d’exploitation en introduisant des sollicitations inédites. Par exemple, une augmentation brutale des volumes à intégrer peut allonger les temps de traitement au point de déséquilibrer l’ensemble d’une chaîne batch. De la même manière, la convergence de plusieurs flux auparavant séparés peut saturer un traitement intermédiaire ou révéler des dépendances de séquencement restées sans effet à plus faible charge. Ces changements constituent autant de tests que l’architecture n’avait jamais subis.
Dans ce contexte, le projet place l’architecture sous une forme de tension inconnue en fonctionnement normal. L’évolution agit comme un révélateur photographique : elle n’introduit pas les vulnérabilités, elle révèle leur existence. Cette distinction entre créer un problème et révéler une faiblesse préexistante modifie la manière d’analyser les incidents survenus pendant la transformation.
Les fragilités exposées par les transformations
Les projets d’évolution du SI rendent visibles quatre grandes familles de vulnérabilités architecturales qui demeurent silencieuses en fonctionnement routinier.
Les dépendances structurelles non documentées constituent la première catégorie. Par exemple, deux applications échangent des données en supposant un format précis, mais cette convention ne figure dans aucune spécification technique ou contrat d’interface. De même, un système attend que certaines tables contiennent toujours des valeurs dans des champs particuliers sans que cette contrainte ne soit formalisée. Ces couplages implicites fonctionnent jusqu’au moment où le projet modifie l’un des éléments concernés. Le flux se rompt alors sans que les équipes ne comprennent immédiatement pourquoi.
Les règles métier dispersées forment une deuxième famille. Typiquement, une logique de validation reste codée dans un job ELT (processus automatisé qui extrait, charge et transforme les données) au lieu d’être appliquée de manière transverse. Autre illustration : une transformation applique un calcul spécifique sur des données sans que cette opération ne soit documentée ailleurs. Lorsque le projet sollicite ces mêmes informations depuis un autre point d’accès, il obtient des résultats incohérents, car la règle ne s’exécute pas uniformément.
Les conventions tacites d’exploitation représentent une troisième catégorie. Ainsi, un traitement B s’exécute toujours après un traitement A en raison d’horaires de planification historiques, sans que cette séquence ne soit explicitement programmée. Dans le même registre, une application suppose qu’une base reste disponible pendant certaines plages horaires sans que cet engagement ne figure dans un contrat de service. Le projet modifie ces conditions et révèle alors les dépendances existantes.
Les points de couplage masqués constituent la quatrième famille. On observe par exemple que des identifiants techniques circulent entre systèmes sans gouvernance formelle. Parallèlement, des références croisées existent entre des tables appartenant à des domaines métier différents sans documentation. Ces liens deviennent problématiques lorsque le projet nécessite de faire évoluer l’un des éléments concernés.
Identifier les causes structurelles par étapes
L’analyse des incidents survenus pendant un projet demande une démarche progressive qui sépare l’événement observable de la condition
Étape 1
La première étape part de l’incident lui-même. Concrètement, il s’agit de répondre à trois questions :
- quel composant dysfonctionne précisément ?
- à quel moment l’erreur apparaît-elle dans la chaîne de traitement ?
- dans quelles conditions se manifeste-t-elle ?
Cette description factuelle permet d’éviter les interprétations prématurées et de circonscrire le périmètre concerné.
Étape 2
La deuxième étape remonte ensuite aux flux et dépendances impliqués.
Pour ce faire, il faut identifier quels systèmes interagissent avec le composant défaillant, quelles données circulent entre eux et quelles transformations s’appliquent sur ces informations. Cette cartographie rapide révèle souvent des liens que la documentation officielle ne mentionnait pas.
Étape 3
La troisième étape identifie alors les hypothèses implicites. Par exemple :
- le système supposait-il que certaines données arriveraient toujours dans un format précis ?
- une séquence d’exécution reposait-elle sur des conditions jamais formalisées ?
- des valeurs étaient-elles présumées stables sans validation explicite ?
Ces questions exposent les conventions tacites qui sous-tendent le fonctionnement apparent.
Étape 4
La quatrième étape sépare ce qui a révélé le problème de ce qui existait déjà
À ce stade, l’analyse montre que le projet a modifié un paramètre, ajouté un connecteur ou fait évoluer un schéma. Cette action constitue le révélateur. En revanche, la fragilité existait avant sous forme de dépendance non documentée, de règle dispersée ou de couplage masqué. Autrement dit, l’architecture contenait déjà la vulnérabilité.
Étape 5
Enfin, la cinquième étape qualifie la nature de la fragilité découverte
S’agit-il d’une documentation manquante, d’un couplage invisible entre composants ou d’une règle métier non formalisée ? Cette qualification oriente les actions à mener : certaines organisations choisissent ainsi de documenter progressivement les conventions découvertes, d’autres privilégient la formalisation des séquences sensibles ou le recensement des points de couplage.
Les incidents qui émergent pendant un chantier d’évolution du SI ne relèvent donc pas seulement du projet lui-même. Ils donnent accès à une lecture plus juste de l’architecture existante, de ses dépendances implicites et de ses points de couplage.
Ressources similaire
