Un outil d’architecture d’entreprise se choisit selon votre maturité, pas selon une démo brillante. Je vous montre comment cadrer le besoin, comparer Boldo, SAP LeanIX, Bizzdesign et Ardoq, puis éviter le piège classique : acheter une plateforme sans gouvernance derrière.
À quoi sert vraiment l’architecture d’entreprise ?
L’architecture d’entreprise sert à relier la stratégie, les investissements et la réalité du système d’information. Pas à produire une belle carte applicative que personne ne regarde après le comité. Une architecture utile aide à répondre à des questions simples, mais rarement bien documentées : Qu’est-ce qu’on a vraiment ? Qui utilise quoi ? Quelle donnée circule où ? Qui est responsable ? Et qu’est-ce qui casse si on touche à cette brique ?
Je vois souvent le même problème chez les clients. La documentation existe, mais elle date d’un projet terminé il y a trois ans. Le CRM a changé, la CDP aussi, un connecteur a été ajouté “temporairement”, et plus personne ne sait si le flux client maître vient du CRM, du data warehouse ou d’un fichier déposé chaque nuit. Résultat, quand il faut arbitrer un projet IA ou décommissionner un outil, on décide avec une information bancale.
La démarche tient en quatre mouvements assez naturels.
- Décrire l’existant. Je pars du réel : applications, processus métier, données, interfaces, contrats, responsables, coûts, risques. Pas besoin de tout modéliser au pixel près. Il faut juste assez de précision pour comprendre les dépendances.
- Définir une cible à 2 ou 3 ans. Je clarifie où l’entreprise veut aller : rationaliser les outils, mieux exploiter la donnée, intégrer une CDP, sécuriser les API, préparer l’IA. Une cible, ce n’est pas un rêve. C’est une direction exploitable pour décider.
- Tracer la trajectoire. Je découpe les chantiers, les dépendances, les prérequis et les risques. Par exemple, impossible de brancher proprement un moteur IA sur les données client si l’identité client est incohérente entre CRM, e-commerce et support.
- Gouverner dans la durée. Je mets à jour l’architecture quand les projets avancent. Sinon, l’outil devient un musée. L’architecture doit rester connectée aux décisions, aux budgets et aux changements du SI.
Les standards comme TOGAF et ArchiMate, portés par The Open Group, donnent un cadre utile. TOGAF aide à structurer la démarche d’architecture. ArchiMate donne un langage commun pour représenter les couches métier, applicative, donnée et technique. Mais le sujet reste très opérationnel : savoir décider avec une information fiable.
| Besoin | Question à poser | Livrable attendu |
| Comprendre l’existant | Quelles applications, données et flux soutiennent nos processus clés ? | Cartographie applicative, flux de données, référentiel des responsables |
| Préparer la cible | Quel SI veut-on dans 2 ou 3 ans pour servir la stratégie ? | Architecture cible, principes, scénarios d’évolution |
| Piloter la trajectoire | Quels chantiers lancer, dans quel ordre, avec quels risques ? | Roadmap, dépendances, arbitrages, portefeuille de transformation |
Pourquoi les anciens référentiels meurent vite ?
Les anciens référentiels meurent vite parce qu’ils demandent beaucoup d’effort à remplir, mais ne rendent pas assez de valeur aux gens qui doivent les alimenter. C’est souvent là que ça casse. Pendant des années, les suites historiques d’architecture d’entreprise ont dominé le marché. Elles savaient tout faire ou presque : modélisation applicative, cartographie des processus, dépendances techniques, capacités métier, trajectoires de transformation, risques, coûts, standards, vues ArchiMate ou TOGAF pour les équipes très matures.
Le problème, c’est que cette richesse a parfois créé une distance énorme avec le terrain. Les architectes comprenaient l’outil. Les autres le subissaient. Un responsable applicatif, une équipe data, un RSSI, une direction financière ou un métier n’a pas envie de passer deux heures dans un modèle complexe pour corriger une date de fin de vie ou ajouter un propriétaire applicatif.
On voit aujourd’hui une vraie fracture. D’un côté, les suites très complètes, solides, adaptées aux grands comptes qui ont déjà une gouvernance EA bien installée. De l’autre, des plateformes SaaS collaboratives, plus simples à prendre en main, pensées pour faire contribuer les équipes qui connaissent vraiment les applications, les données, les coûts et les risques.
| Suites historiques | Très riches, très structurées, efficaces si l’organisation sait déjà gouverner son référentiel. |
| Plateformes SaaS collaboratives | Plus accessibles, plus orientées contribution, meilleures pour garder les données vivantes. |
Le vrai sujet n’est pas juste l’outil. C’est de transformer le référentiel en actif vivant. Pas en musée applicatif qu’on dépoussière une fois par an avant un comité de direction. J’ai vu des clients avec de très beaux outils, des licences chères, des modèles propres sur le papier… Et pourtant personne ne savait qui devait maintenir quoi. Résultat, tout le monde regardait les données avec méfiance.
Les API, c’est-à-dire les interfaces qui permettent aux systèmes d’échanger automatiquement des données, peuvent aider. Les connecteurs avec une CMDB, la base qui recense les composants IT, un ITSM, l’outil de gestion des incidents et demandes, le cloud, le SSO, l’authentification centralisée, ou même des tableurs peuvent accélérer la mise à jour. Mais ça ne remplace jamais une responsabilité claire.
Un référentiel EA est probablement en train de mourir quand vous voyez ces signaux :
- Les données sont mises à jour juste avant les comités.
- Personne ne sait qui est propriétaire d’une information.
- Les métiers ne se connectent jamais à l’outil.
- Les architectes passent leur temps à relancer au lieu d’analyser.
- Les exports Excel deviennent plus utilisés que la plateforme.
- Les décisions se prennent ailleurs, dans des slides ou des réunions.
- Les équipes disent “Je ne fais pas confiance aux données”.
Que valent Boldo, SAP LeanIX, Bizzdesign et Ardoq ?
Ces quatre outils ne jouent pas exactement dans la même cour, et c’est souvent là que les comparatifs deviennent trompeurs. Je ne les choisirais pas avec les mêmes critères, ni pour les mêmes équipes. Le bon outil, c’est celui qui colle à votre maturité, à votre gouvernance, et surtout à la capacité réelle des équipes à l’utiliser sans le contourner au bout de trois mois.
Boldo se positionne comme une plateforme nouvelle génération, collaborative et souveraine. Je la trouve intéressante pour les organisations qui veulent embarquer largement les métiers, l’IT, les architectes, parfois même les équipes produit, sans tomber dans une usine à gaz dès le départ. L’intérêt est dans l’adoption, la simplicité, la capacité à créer un référentiel partagé. Je resterais prudent sur les fonctionnalités avancées tant qu’elles ne sont pas vérifiées dans votre contexte, mais le positionnement est clair : rendre l’architecture plus accessible et plus collaborative.
SAP LeanIX est une référence solide sur l’Application Portfolio Management, donc la gestion du portefeuille applicatif. Là, on parle de transparence sur les applications, les coûts, les risques, les redondances, les obsolescences et les trajectoires de transformation. Depuis son rachat par SAP en 2023, LeanIX a encore plus de sens dans les environnements SAP ou les grands programmes de transformation IT. Ce n’est pas juste un outil de dessin, c’est un outil pour rationaliser et piloter.
Bizzdesign convient mieux aux grandes organisations qui ont déjà une pratique d’architecture d’entreprise structurée. Si vous travaillez avec ArchiMate, un langage standard pour modéliser l’architecture, et que vous devez relier stratégie, processus, applications et technologies, c’est un candidat sérieux. Il demande par contre une vraie discipline de modélisation.
Ardoq est plus orienté donnée, graphes et analyses dynamiques. Son intérêt est fort quand vous voulez visualiser les dépendances, simuler les impacts, et alimenter le référentiel avec des données structurées plutôt qu’avec seulement des schémas faits à la main. J’ai vu ce type d’approche débloquer des discussions compliquées, parce qu’on arrête de débattre sur des impressions.
| Solution | Meilleure situation d’usage | Point fort | Point de vigilance |
| Boldo | Organisation qui veut démocratiser l’architecture et embarquer plus largement les équipes. | Approche collaborative, simple à adopter, avec un positionnement souverain. | Vérifier les fonctionnalités avancées sur vos cas d’usage réels. |
| SAP LeanIX | Rationalisation applicative, APM, transformation IT, contexte SAP. | Très fort pour donner de la visibilité sur le parc applicatif. | Peut être trop orienté portefeuille applicatif si votre besoin est surtout modélisation fine. |
| Bizzdesign | Grande organisation avec une pratique EA mature et des comités d’architecture exigeants. | Modélisation robuste, cadres comme ArchiMate, vues multi-niveaux. | Demande une gouvernance et une discipline déjà en place. |
| Ardoq | Organisation qui veut piloter l’architecture par la donnée et les dépendances. | Graphes, analyses d’impact, visualisations dynamiques. | La qualité des analyses dépend fortement de la qualité des données injectées. |
Comment choisir sans se tromper ?
Pour choisir sans se tromper, je pars toujours de trois choses : votre maturité en architecture d’entreprise, votre cas d’usage prioritaire, et votre capacité réelle à maintenir les données dans le temps. Parce qu’un outil d’EA, ce n’est pas juste une belle cartographie. C’est un référentiel vivant. Si personne ne l’alimente, il devient faux très vite.
Une organisation qui veut reprendre la main sur son parc applicatif n’a pas forcément besoin de la même plateforme qu’un grand groupe déjà structuré autour de TOGAF, ArchiMate, de comités d’architecture et de modèles multi-couches. TOGAF, pour faire simple, c’est un cadre de méthode pour organiser l’architecture. ArchiMate, c’est un langage de modélisation. Très utile, mais pas toujours nécessaire au départ.
Je regarde surtout ces critères avant de choisir :
- La maturité EA, c’est-à-dire votre capacité à produire, valider et maintenir des vues d’architecture.
- Le nombre d’applications et le volume de dépendances entre applications, données, processus et infrastructures.
- Le besoin de souveraineté, notamment si les données doivent rester en Europe ou en environnement maîtrisé.
- La facilité de contribution pour les métiers, parce qu’un outil réservé aux architectes finit souvent isolé.
- Les intégrations avec l’existant, comme CMDB, ITSM, ERP, annuaires, outils DevOps ou référentiels de données.
- La qualité des vues pour les dirigeants, parce qu’ils ne liront pas un modèle ArchiMate brut.
- Le modèle de données, les API, la gouvernance, les droits, les workflows de validation.
- Les coûts de mise en œuvre et surtout le coût d’adoption interne. Formation, conduite du changement, temps passé à nettoyer les données.
| Objectif prioritaire | Type d’outil à privilégier |
| Rationalisation applicative | Une plateforme simple, orientée inventaire, scoring, coûts, redondances et obsolescence. |
| Modélisation avancée | Un outil robuste compatible ArchiMate, multi-couches, avec gouvernance de modèles. |
| Collaboration large | Une solution accessible aux métiers, avec formulaires, vues simples et workflows. |
| Analyse dynamique des dépendances | Un outil connecté aux sources techniques, capable d’exploiter logs, flux, CMDB ou discovery. |
Le POC doit tester un vrai scénario. Pas une démo générique avec trois applications fictives. Par exemple : identifier les applications redondantes sur un domaine métier, mesurer l’impact d’un arrêt applicatif, ou produire une vue comité exécutif sur les risques du SI.
J’ai eu un client qui voulait cartographier tout son SI dès le départ. Plusieurs centaines d’applications, des flux partout, des métiers pas alignés. On a réduit le périmètre à un seul domaine critique. En six semaines, ils avaient une vision exploitable, des décisions concrètes, et surtout une méthode réutilisable. C’était beaucoup plus utile qu’un grand programme de cartographie qui aurait duré un an.
Avant signature, je poserais ces questions :
- Quel problème métier doit être résolu dans les trois premiers mois ?
- Qui va maintenir les données, et avec quel temps disponible ?
- Quelles sources existantes peuvent être connectées dès le départ ?
- Les métiers peuvent-ils contribuer sans formation lourde ?
- Les dirigeants auront-ils des vues lisibles et actionnables ?
- Le modèle de données est-il flexible ou trop rigide ?
- Les API permettent-elles d’automatiser les mises à jour ?
- Quel est le coût complet, licence, intégration, nettoyage, formation et gouvernance inclus ?
Qu’est-ce qu’un outil EA ne fera jamais ?
Je vois souvent le même piège : on choisit un outil d’architecture d’entreprise, ou EA pour Enterprise Architecture, comme si ça allait remettre de l’ordre tout seul. Ça aide, clairement. Mais ça ne remplace pas la gouvernance.
Un outil EA peut centraliser les applications, visualiser les dépendances, relier les flux, historiser les changements et aider à prendre de meilleures décisions. Mais il ne décidera jamais qui est vraiment owner d’une application. Il ne va pas arbitrer une dette technique sensible parce qu’un métier refuse de payer la modernisation. Il ne va pas imposer une trajectoire cible si le comité de direction n’est pas aligné. Et surtout, il ne garantit pas que les données restent fiables dans le temps.
J’ai vu un client avec un très bon outil, très bien paramétré, mais personne ne mettait à jour les applications après les projets. Résultat simple : au bout de six mois, le référentiel était joli, mais faux. Et un référentiel faux, c’est pire que pas de référentiel, parce qu’il donne une illusion de maîtrise.
La réussite tient souvent à des rituels assez simples, pas à une usine à gaz. Il faut poser quelques règles et les tenir dans la durée :
- Définir clairement les responsabilités, avec un owner métier et un owner IT par actif important.
- Organiser des revues régulières, même courtes, pour valider les changements.
- Mettre des règles de nommage simples, sinon chacun crée sa variante.
- Ajouter des contrôles qualité sur les champs clés, comme criticité, statut, owner, date de revue.
- Mettre un workflow de validation pour éviter que tout le monde modifie tout.
- Suivre des indicateurs d’obsolescence, par exemple les applications sans mise à jour depuis douze mois.
- Aligner finance, sécurité, data et métiers, parce que l’architecture n’est pas un sujet réservé à l’IT.
Je préfère toujours commencer petit. Les applications critiques. Les flux majeurs. Les domaines métier prioritaires. Puis on élargit. C’est moins impressionnant au départ, mais beaucoup plus durable.
Avec l’IA, l’architecture d’entreprise devient encore plus utile. Pour faire de bons projets IA, il faut savoir où sont les données, quels systèmes les produisent, qui les consomme, quelles règles s’appliquent et quels risques existent. Mais soyons clairs : l’IA ne sauvera pas un référentiel sale. Elle va juste accélérer le bruit si la base est mauvaise.
| Ce que l’outil fait | Ce que l’organisation doit faire |
| Centraliser les applications, flux, données et technologies. | Nommer les owners et clarifier les responsabilités. |
| Visualiser les dépendances et les impacts. | Arbitrer les priorités, les budgets et les dettes techniques. |
| Historiser les changements. | Mettre à jour régulièrement les informations. |
| Déclencher des workflows de validation. | Faire respecter les règles de gouvernance. |
| Produire des indicateurs et des alertes. | Décider quoi faire quand un risque apparaît. |
Vous voulez un outil ou une vraie capacité de décision ?
Le bon outil d’architecture d’entreprise, ce n’est pas celui qui coche le plus de cases. C’est celui qui colle à votre maturité, à vos priorités et à votre capacité à faire vivre le référentiel. Boldo, SAP LeanIX, Bizzdesign et Ardoq peuvent tous être pertinents, mais pas pour les mêmes raisons. Je regarde d’abord le cas d’usage, l’adoption, la gouvernance et la qualité des données. Après seulement, je regarde les fonctionnalités. Si vous posez le sujet comme ça, vous évitez l’achat vitrine et vous gagnez un vrai support pour décider, prioriser et transformer votre SI plus proprement.
FAQ
- Qu’est-ce qu’un outil d’architecture d’entreprise ?
C’est une plateforme qui centralise la connaissance du système d’information : applications, données, processus, flux, responsabilités, dépendances et trajectoires de transformation. Son rôle est d’aider les équipes à comprendre l’existant, préparer la cible et prendre de meilleures décisions d’investissement. - Quelle différence entre cartographie SI et architecture d’entreprise ?
La cartographie SI décrit surtout les applications, les flux et les dépendances. L’architecture d’entreprise va plus loin : elle relie ces éléments à la stratégie, aux processus métier, aux projets, aux risques, aux coûts et aux arbitrages. La cartographie est souvent le point de départ, pas le résultat final. - SAP LeanIX, Bizzdesign, Ardoq et Boldo répondent-ils au même besoin ?
Pas exactement. SAP LeanIX est très orienté rationalisation applicative et transparence du portefeuille. Bizzdesign convient bien aux pratiques EA matures et structurées. Ardoq mise beaucoup sur la donnée, les dépendances et les analyses dynamiques. Boldo se positionne plutôt sur une approche collaborative, nouvelle génération et souveraine. - Comment réussir un projet d’architecture d’entreprise ?
Je conseille de commencer par un périmètre utile : applications critiques, domaine métier prioritaire, programme de transformation ou rationalisation applicative. Ensuite il faut définir les owners, les règles de mise à jour, les rituels de revue et les décisions que le référentiel doit vraiment aider à prendre. - Un outil EA peut-il remplacer une gouvernance d’architecture ?
Non. L’outil aide à structurer, visualiser, partager et analyser. Mais il ne définit pas les responsabilités, ne tranche pas les conflits de priorité et ne maintient pas les données tout seul. Sans gouvernance claire, même le meilleur outil finit par devenir une base obsolète.
A propos de l’auteur
Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des entreprises sur le tracking server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA, le SEO et la structuration de la donnée. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Mon sujet, c’est simple : aider les équipes à mieux relier leurs données, leurs outils et leurs décisions business. Si vous voulez cadrer une démarche data, IA ou architecture outillée, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.