D’après la dernière étude de l’Observatoire de la Maturité Data, 88 % des entreprises françaises estiment pouvoir améliorer la performance de leur entreprise grâce à une meilleure exploitation de leurs données. Logique : la valeur d’une organisation passe de plus en plus par sa capacité à collecter, analyser et transformer les données en leviers de business. Mais on oublie souvent que cette dimension data first impacte directement l’architecture d’entreprise. Et c’est là que TOGAF (The Open Group Architecture Framework) refait surface. Ou comment concilier la rigueur méthodologique d’un framework d’architecture avec la frénésie data qui s’impose à tous…
L’essor des approches orientées données et l’impact sur les priorités de l’architecture d’entreprise
Tout le monde, sur le papier, voudrait être data-driven. Derrière ça, on trouve une réalité : la compétitivité dépend de la capacité à valoriser l’information, à la fois pour l’opérationnel (mesurer, ajuster vite) et pour le stratégique (anticiper l’avenir, innover, personnaliser).
Dans une architecture d’entreprise classique, on s’intéressait beaucoup à la partie applicative, aux flux, aux couches techniques. Désormais, la dimension data devient un axe transversal :
- Comment stocker ?
- Qui a accès ?
- Quelles règles de qualité et de gouvernance ?
- Comment interconnecter les silos de données pour éviter les redondances ?
Si on néglige ces questions, on accumule vite une dette technique : data dupliquées, rapprochements manuels, sécurité hasardeuse… D’où l’évolution des priorités : l’architecture doit intégrer le modèle de données comme une pièce maîtresse, pas comme un détail annexe.
Le rôle de TOGAF comme cadre d’adaptation face à cette évolution
TOGAF, c’est quoi ? Il s’agit d’un framework structuré qui guide la création et l’évolution de l’architecture d’entreprise, basé sur le concept d’ADM (pour « Architecture Development Method »), articulé en différentes phases (depuis la vision initiale jusqu’à la gouvernance continue).
Si, autrefois, on considérait TOGAF comme un truc un peu rigide, il est aujourd’hui considéré comme un outil adaptable, qui peut intégrer la dimension data de manière cohérente.
L’idée est simple : TOGAF est un ensemble de best practices permettant de décrire et de planifier l’ensemble du SI, y compris la couche data.
Ainsi, quand on revoit les processus métiers, on y associe la définition des flux de données critiques, les règles de qualité, et la stratégie de stockage. On met la data au cœur de la réflexion, ce qui permet de conduire (ou d’accélérer) la transformation de l’organisation.
La place des données dans les phases du TOGAF ADM
Pour rappel, l’ADM s’articule autour de plusieurs phases (A à H). Sans faire un exposé exhaustif, on peut pointer quelques moments clés où la dimension data a ici tout son intérêt.
D’abord, Phase A (Architecture Vision) :
On définit la vision, la portée, les objectifs. Logique de clarifier la vision data : quels cas d’usage ? Quelles ambitions d’exploitation (BI, IA) ? Quelles obligations de conformité (RGPD, eIDAS, etc.) ?
Puis, Phase B (Business Architecture) :
On identifie les processus métiers. L’occasion d’associer à chaque process les jeux de données manipulés, leur criticité, etc.
Ensuite, Phase C (Information Systems Architectures) :
Ici, on traite la couche applicative et data. On formalise les modèles de données, les relations, la politique de stockage. On détermine l’articulation entre data en temps réel vs data analytiques, par exemple.
Enfin, Phase D (Technology Architecture) :
On regarde l’infrastructure en elle-même, la topologie des serveurs, le cloud vs on-prem, la segmentation réseau… tout ce qui touche à l’hébergement, la performance, la sécurité.
Dans chacune de ces phases, la question data est centrale : comment modéliser, qui accède, où conserver, comment intégrer…
D’où l’importance de la prise en compte systématique, pour éviter le patchwork.
Créer une stratégie et une organisation data-first avec TOGAF
Dans une organisation data-first, on ne veut évidemment pas juste « subir » la donnée, on veut la piloter.
Et justement, TOGAF peut servir de canevas pour :
- Définir un poste en charge de la data governance (Data Owner, Data Steward, etc.),
- Établir la cartographie des actifs data, le dictionnaire de données, les règles d’or sur la qualité et la confidentialité,
- Mettre en place des guidelines pour tout projet, afin de garantir que chaque nouvelle appli respecte le modèle data défini, et ne recrée pas un silo.
Ça peut sembler un brin formel, mais c’est ce qui garantit la cohérence : on évite que chaque BU déploie son datalake perso, qu’on se retrouve avec 15 versions d’une même info client.
On centralise (ou au moins on harmonise) la logique data, tout en laissant la souplesse d’évolution (puisque TOGAF encourage la mise à jour continue).
Bien sûr tout cela implique une montée en compétences des équipes sur TOGAF.
Interopérabilité et TOGAF : lever les barrières des données dans les écosystèmes d’entreprise
Les entreprises n’évoluent pas en vase clos : elles échangent des data avec des partenaires, filiales, clients… L’interopérabilité est donc un axe essentiel.
Or, sans référentiel data clair, comment aligner les formats, les protocoles, les modèles ?
TOGAF encourage une vision globale de l’architecture, y compris le dimensionnement des flux inter-organisationnels. S’il y a un module CRM qui doit synchroniser des contacts avec le système d’une filiale, c’est plus facile si on possède une architecture Data partagée.
Sinon, c’est la foire aux conversions ou aux scripts maison.
En clarifiant les standards, la sémantique, les contrats d’interface, on lève des barrières qui handicapent souvent la circulation des infos. On peut alors développer des solutions plus homogènes, plus évolutives, et on profite d’un SI plus agile, moins enfermé dans des silos.
En bref, la data en tant que pivot oblige à repenser l’architecture d’entreprise de manière encore plus intégrée, et TOGAF fournit une trame pour orchestrer tout ça, sans devoir improviser.