Construire une architecture cible à partir des contraintes de terrain

10 novembre 2026

Situation illustrative : un groupe industriel exploite douze sites, un ERP central, plusieurs applications locales et des équipements de production qui ne tolèrent pas une interruption réseau. Le comité de direction demande une architecture cible « cloud et standardisée ». Le DSI pourrait produire une carte séduisante, alignée sur les catalogues des fournisseurs. Son vrai travail est plus difficile : décider ce qui doit être commun, ce qui doit rester proche des opérations et quelles dépendances l’entreprise accepte. Une cible utile ne dessine pas un avenir parfait. Elle organise des compromis exécutables.

Commencer par les impossibilités, pas par les solutions

L’erreur initiale consiste à demander : « Quelle technologie voulons-nous ? » La question opératoire est : « Quelles contraintes ne pouvons-nous pas ignorer ? » Une ligne de production peut exiger une latence stable. Une donnée sensible peut imposer des conditions particulières de localisation et d’accès. Un contrat peut rendre une sortie coûteuse. Une compétence rare peut interdire une technologie pourtant élégante. Un projet déjà engagé peut limiter temporairement les options.

Le DSI doit donc constituer un registre des contraintes, avec pour chacune sa source, son propriétaire, sa durée probable et sa marge de négociation. Certaines sont absolues ; d’autres ne sont que des habitudes déguisées. Cette distinction empêche de sanctuariser l’existant tout en évitant de bâtir une cible inexécutable. Le comité d’architecture ne valide alors plus des produits isolés : il vérifie qu’une décision respecte ces contraintes, nomme le risque résiduel et désigne l’autorité qui l’accepte.

Transformer les irritants en exigences d’architecture

Les incidents récurrents, les doubles saisies, les contournements locaux, les délais de support et les restaurations incertaines sont des informations d’architecture. Ils révèlent les endroits où le système réel contredit le système officiel. Un inventaire applicatif ne suffit donc pas. Il faut observer les flux critiques, interroger les responsables opérationnels et suivre quelques transactions de bout en bout : prise de commande, lancement de fabrication, expédition, clôture comptable ou gestion d’un incident cyber.

Chaque irritant doit être reformulé en exigence vérifiable. « Le réseau est mauvais » devient, par exemple, « le site doit poursuivre telle opération pendant une rupture de liaison ». « Les données sont incohérentes » devient « telle donnée possède un référentiel, un responsable et une règle de synchronisation ». La cible commence lorsque les plaintes deviennent des décisions testables.

Séparer le socle commun des exceptions locales

Dans une organisation multisite, centraliser sans nuance éloigne l’IT du terrain ; laisser chaque site décider fabrique des coûts cachés et des failles. L’arbitrage porte sur la frontière. Les identités, les exigences de cybersécurité, les référentiels, les contrats structurants, les standards de poste et les règles d’intégration ont vocation à former un socle commun. La continuité d’un atelier, certains équipements spécialisés ou une intervention urgente peuvent justifier une capacité locale.

Toute exception doit cependant avoir un motif, un responsable, une durée de réexamen et un mode de raccordement au support commun. Sans ces quatre éléments, l’exception devient un système parallèle. À l’inverse, un standard incapable de traiter une contrainte documentée n’est pas un standard : c’est une préférence centrale imposée aux opérations.

Construire la trajectoire avant de figer la cible

La cible doit être décrite avec son chemin d’accès. Première étape : cartographier les capacités critiques, leurs dépendances techniques, leurs propriétaires et leurs points de rupture. Deuxième étape : définir quelques principes de décision, par exemple l’identité commune, la réversibilité contractuelle, l’exploitation observable et le maintien local des fonctions indispensables en cas de coupure. Troisième étape : classer les composants entre conserver, sécuriser, remplacer, découpler ou retirer.

Vient ensuite le séquencement. On ne remplace pas un ERP, un réseau industriel et un dispositif d’identité simultanément si les mêmes experts portent les trois chantiers. Les dépendances, les fenêtres métier et la charge des équipes commandent l’ordre. Chaque étape doit produire un état intermédiaire exploitable, et non une longue période où l’ancien et le nouveau restent durablement imbriqués sans responsabilité claire.

Arbitrer l’hybride sans dogme fournisseur

Cloud public, infrastructure dédiée, hébergement managé et traitement en périphérie ne sont pas des camps idéologiques. Ce sont des réponses différentes à des contraintes de disponibilité, de sensibilité, de performance, de compétences et de réversibilité. Une charge stable associée à un équipement physique peut rester hébergée. Un service variable et standardisable peut bénéficier du cloud public. Une fonction industrielle critique peut nécessiter une autonomie locale synchronisée avec le système central.

Le dirigeant IT doit rendre le compromis explicite : quel gain attend-il, quelle dépendance crée-t-il, quel mode dégradé conserve-t-il et comment pourra-t-il changer de solution ? Le coût affiché ne suffit pas. Il faut intégrer l’exploitation, le réseau, la supervision, les compétences, les sorties de données et la coexistence pendant la migration.

Piloter par des preuves et décider des renoncements

Une architecture cible se gouverne avec peu d’indicateurs, mais reliés aux décisions : part des flux critiques documentés, exceptions sans propriétaire, composants sans scénario de reprise testé, dépendances à un fournisseur sans solution de sortie, applications hors trajectoire, capacité consommée par le maintien de l’existant, étapes intermédiaires réellement atteintes. Ces mesures ne prouvent pas la perfection ; elles montrent si la maîtrise progresse.

Les erreurs fréquentes sont prévisibles : confondre cible et catalogue technologique, nier les contrats en cours, sous-estimer la saturation des équipes, repousser la cybersécurité à la fin, ou conserver toutes les exceptions pour éviter le conflit. Le dernier arbitrage revient au dirigeant : quels risques réduire maintenant, quels écarts accepter temporairement et quels projets arrêter pour libérer une capacité réelle ? C’est ici que l’architecture devient gouvernance. Dans l’esprit de Révolution Numérique !, elle relie les choix technologiques aux enjeux de décision, de résilience et de dépendance. La bonne cible n’est pas la plus moderne sur le papier ; c’est celle dont chaque compromis est assumé, financé, mesurable et révisable.