Insights
Réflexions sur l'architecture d'entreprise
Analyses, retours d'expérience et points de vue sur l'EA, l'intégration et la transformation augmentée par l'IA.
Sortir du core banking historique : big bang, migration progressive ou évidement du cœur
Remplacer le système central d'une banque est presque toujours instruit comme le choix d'un progiciel, alors que la décision qui engage le plus est la manière d'en sortir. Trois stratégies — tout basculer d'un coup, migrer par lots, vider le cœur de ses fonctions avant de le remplacer — et ce que chacune exige réellement : gel des évolutions, coexistence de deux systèmes de référence, réconciliation comptable.
Personne ne se souvient pourquoi : documenter les décisions d'architecture pour pouvoir les rouvrir
Les schémas décrivent ce qui a été construit, jamais ce qui aurait pu l'être autrement. Quand les raisons d'un choix se perdent, l'organisation n'a plus que deux attitudes : sacraliser l'existant ou le remettre en cause à chaque arrivée. Pourquoi les registres de décisions échouent si souvent à l'éviter, ce qu'une décision doit consigner pour pouvoir être rouverte, et pourquoi ce sont les hypothèses, plus que les décisions, qu'il faut suivre.
Le portefeuille de projets est la véritable architecture cible : ce que les arbitrages budgétaires dessinent sans le dire
Le schéma directeur décrit une cible ; la liste des projets financés chaque année en construit une autre, sans que personne ait décidé d'en changer. Pourquoi la cible et le portefeuille divergent, comment lire un portefeuille comme une trajectoire d'architecture, les trois signaux qui révèlent l'écart, et comment faire entrer la cohérence avec la cible dans l'arbitrage plutôt que dans un avis après coup.
Un principe d'architecture que personne ne peut enfreindre ne sert à rien : écrire des principes qui arbitrent
La plupart des listes de principes d'architecture sont validées à l'unanimité, puis ne tranchent plus aucune décision. Non parce qu'elles sont mal appliquées, mais parce qu'elles sont écrites pour être approuvées. Le test qui distingue un principe d'une déclaration, ce qu'un principe doit contenir pour arbitrer, pourquoi les principes se contredisent et comment éprouver une liste sur les décisions déjà prises.
Quand le métier décide sans l'architecture : ce n'est pas un problème de pouvoir, c'est un problème de mandat
Une direction métier choisit un outil, signe le contrat, puis demande à l'architecture de le raccorder. Réclamer un droit de veto ne change rien à ce scénario. Pourquoi la décision est rationnelle vue du métier, pourquoi elle se prend dans des circuits où l'architecture n'est pas, et ce qu'un mandat explicite — des critères, un moment, une dérogation signée — change à la place d'un pouvoir qu'on n'obtiendra pas.
Exposer ses API à des partenaires : une interface externe est un engagement, pas un connecteur
Une API ouverte à des tiers perd tout ce qui rendait l'interface interne gouvernable : un arbitre commun, la connaissance des usages, la liberté de retirer. Ce qui change quand le consommateur n'appartient plus à l'organisation, pourquoi la politique d'évolution doit être publiée avant le premier partenaire, et comment protéger le système d'information de ceux qu'on a invités à s'y connecter.
Le modèle d'habilitations est un modèle métier : pourquoi les droits d'accès décrivent l'organisation d'il y a dix ans
La revue annuelle valide un stock qu'elle n'est pas en mesure de juger, pendant que le mécanisme qui l'a produit continue de tourner. Pourquoi les droits ne s'accumulent que dans un sens, ce que recouvrent les trois natures de droit constamment confondues, et où doit vivre l'autorité qui traduit une situation en accès.
Le cahier des charges a déjà choisi l'architecture : ce que l'appel d'offres décide avant l'architecte
Le dossier de consultation tranche le découpage, la forme des exigences, le modèle contractuel et les critères de choix des mois avant la première réunion de conception — et aucun de ces arbitrages n'est instruit comme une décision d'architecture. Ce qu'une consultation ferme sans le dire, ce qu'il faut y écrire, et comment évaluer une réponse sur ce qu'elle rend possible ensuite.
L'architecture cible ne vaut rien sans trajectoire : concevoir les états intermédiaires
Les schémas directeurs ne décrivent presque jamais l'état dans lequel l'organisation se trouvera réellement, parce que la transformation s'arrête toujours quelque part entre le départ et la cible. Ce que doit vérifier un état intermédiaire pour être vivable, comment concevoir un régime de coexistence, et pourquoi la sortie du provisoire s'écrit au moment où on l'ouvre.
Ce qu'on n'éteint jamais : le décommissionnement est une décision d'architecture, pas une tâche de fin de projet
Un parc applicatif ne décroît presque jamais, non par négligence mais parce qu'arrêter un système est la seule activité du cycle de vie sans sponsor, sans budget et sans bénéfice visible. Les quatre verrous qui empêchent réellement d'éteindre une application, et pourquoi les conditions du retrait s'écrivent à la mise en service.
Standard ou spécifique : l'arbitrage que l'on croit économique et qui est structurel
Le choix entre progiciel et développement sur mesure est presque toujours instruit comme une comparaison de coûts, alors qu'il décide de ce que l'organisation pourra encore changer. Une grille fondée sur les capacités métier, et l'anatomie de la dérive la plus coûteuse : le paramétrage qui devient du spécifique déguisé.
L'intégration n'est pas de la plomberie : le contrat d'interface est un actif d'architecture
Le désordre d'intégration ne vient presque jamais du bus qu'on a choisi, mais d'interfaces sans propriétaire, sans définition et sans règle d'évolution. Ce que contient réellement un contrat d'interface, comment trancher entre synchrone et événementiel, et pourquoi la capacité d'une organisation à changer se lit dans ses interfaces.
Concevoir pour la panne : la résilience est une propriété d'architecture, pas un plan de reprise
Le plan de continuité répond au sinistre franc ; les incidents réels sont partiels, lents et se propagent. Comment traduire les objectifs de continuité en décisions de conception — cloisonnement, modes dégradés, maîtrise de l'état — et réserver le bon niveau de résilience aux capacités métier qui le justifient.
La dette technique n'est pas un problème technique : c'est une décision de financement
Tant que la dette reste un sujet d'ingénieurs, elle ne trouve jamais de budget. Comment la qualifier, la rattacher aux capacités métier qu'elle fragilise, et la rendre arbitrable en comité — y compris la part qu'on choisit délibérément de ne jamais rembourser.
Choisir le cloud sans s'y enfermer : trajectoire, réversibilité et souveraineté
Le vrai risque du cloud n'est pas le cloud, c'est l'irréversibilité. Pourquoi la dépendance à un fournisseur est une propriété d'architecture qui se décide en amont, ce que le nouveau cadre réglementaire européen change, et comment garder une porte de sortie sans renoncer aux bénéfices.
Coût total de possession : pourquoi le vrai prix d'une application se décide dans l'architecture
Le TCO n'est pas une ligne du budget, c'est une propriété de conception. Ce que recouvre vraiment le coût total de possession, pourquoi il est devenu vital, comment le calculer — et pourquoi l'essentiel se joue au moment des choix d'architecture, bien avant la première facture.
Gouvernance d'architecture : cadrer sans freiner
Quand le comité d'architecture devient un goulot d'étranglement, les équipes contournent la gouvernance au lieu de la suivre. Comment passer du contrôle a priori à un cadre qui oriente — guardrails, décisions tracées, assurance automatisée — sans sacrifier la cohérence.
Gouvernance de la donnée : qui possède quoi, et pourquoi c'est une question d'architecture avant d'être une question d'outil
La plupart des programmes de gouvernance de la donnée échouent non par manque de plateforme, mais par flou sur la propriété, les définitions et le cycle de vie. Pourquoi la gouvernance se décide dans l'architecture — et comment poser un modèle qui tient.
Sécurité par conception : intégrer la menace dans le dessin de l'architecture, pas après
Traitée comme une couche ajoutée en fin de projet, la sécurité coûte cher et protège mal. Comment intégrer la modélisation des menaces, la segmentation et les exigences de souveraineté dès les vues d'architecture d'entreprise.
Cartographier ses capacités métier : l'artefact d'architecture le plus sous-estimé
La carte des capacités métier est la lentille la plus puissante pour prioriser les investissements SI et aligner technologie et stratégie. Pourquoi l'inventaire applicatif ne suffit pas — et comment construire la vôtre.
L'architecte augmenté : ce que l'IA change vraiment au métier
Au-delà du buzz, comment l'IA transforme concrètement le quotidien d'un architecte d'entreprise — et où sa valeur se concentre.
TOGAF n'est pas une religion : comment l'adapter à votre contexte
Comment exploiter TOGAF sans tomber dans le dogmatisme — un guide pragmatique pour les DSI qui veulent du résultat, pas un cycle ADM complet.
Moderniser un SI bancaire en Afrique : 5 réalités que les frameworks ignorent
Bank Al-Maghrib, BCEAO, talents disponibles, contraintes télécoms : pourquoi un programme de transformation à Casablanca ou Abidjan ne se pilote pas comme à Francfort.
L'IA native, le vrai différenciateur de l'architecture d'entreprise
Pourquoi greffer de l'IA sur une plateforme existante ne suffit pas, et ce que change une intégration native sur chaque module.
TCO : le coût caché des plateformes d'EA historiques
Le prix de la licence n'est que la partie émergée. Décryptage des huit strates du coût total de possession d'une plateforme d'architecture d'entreprise — et un cadre concret pour l'estimer.