Personne ne commande une étude à une administration sans planificateurs
Le ministère veut une ligne nouvelle entre deux métropoles. Il rédige une lettre de mission et l'adresse à l'autorité d'infrastructure. Si cette autorité n'a ni direction de la planification, ni règles de tracé, ni archives des lignes existantes, la lettre reste sur un bureau. Personne ne sait qui doit l'ouvrir, ni avec quelle méthode y répondre.
Avant la première étude de ligne, il faut donc une autorité capable de la mener : des planificateurs, un règlement, des archives, un comité qui tranche. La lettre de mission ne crée rien de tout cela. Il faut que ce soit déjà en place.
En architecture d'entreprise, ce travail préalable porte un nom : la phase préliminaire de l'ADM. Elle livre l'organisation, les règles et les outils qui permettront de produire des architectures, cycle après cycle, sans en dessiner aucune elle-même.
Ce billet suit la phase dans l'ordre du TOGAF Standard, puis consacre sa seconde moitié à ce que la phase laisse de plus durable : les principes d'architecture. Comment on les écrit, comment ils s'emboîtent, ce qui en fait de bons principes, et comment ils vivent ensuite de la phase A à la phase D.
La phase préliminaire ne dessine pas la ligne. Elle crée l'autorité qui saura la dessiner, et les règles que cette autorité appliquera à toutes les lignes suivantes.
Vue d'ensemble : préparer, adapter, poser les règles
La phase préliminaire a trois finalités. Préparer et initier : mettre l'organisation en état de réussir ses travaux d'architecture, en identifiant qui est concerné et qui décide. Adapter le cadre : prendre TOGAF, et les autres cadres déjà en place dans la maison, pour en faire une méthode qui parle la langue de l'organisation. Définir les principes : écrire les règles durables qui guideront les choix.
Le standard regroupe ses objectifs en deux familles.
Déterminer la capacité d'architecture désirée : relire le contexte organisationnel, délimiter les organisations impactées, recenser les cadres, méthodes et processus déjà en place, fixer une cible de maturité.
Établir cette capacité : définir le modèle d'organisation de l'architecture d'entreprise, mettre en place les processus et les ressources de la gouvernance, choisir et déployer les outils, poser les principes.
Sur le cadran, Préliminaire est la seule tuile hors du cycle. Sur le réseau, l'autorité d'infrastructure ne se recrée pas à chaque ligne nouvelle ; de même, on ne repasse pas par la phase préliminaire à chaque itération. On y revient quand la capacité elle-même doit changer : une fusion, une nouvelle réglementation, un périmètre qui s'élargit à des partenaires.
La phase préliminaire répond à cinq questions : où (quel périmètre), quoi (quel travail d'architecture), pourquoi (quels moteurs), qui (quelle équipe, quelle gouvernance), comment (quel cadre, quels outils). Le reste de l'ADM suppose ces réponses acquises.
Les six étapes
Côté réseau ferré, créer la direction de la planification suit un ordre. On fixe d'abord son ressort territorial, puis on la raccorde aux instances qui existent déjà, le régulateur et l'autorité de sécurité. On la dote d'équipes, on lui donne un règlement, on adapte les référentiels européens à son réseau, et enfin on l'outille en cartes et en registres.
Le standard décrit la phase préliminaire en six étapes, dans le même esprit.
Délimiter les organisations impactées. Quelles unités sont au cœur du périmètre, lesquelles sont touchées de façon indirecte, lesquelles sont seulement à informer. Les partenaires, fournisseurs et clients font partie de la réponse quand l'entreprise au sens TOGAF les inclut.
Confirmer les cadres de gouvernance et de support. L'architecture ne gouverne jamais seule. Elle s'insère dans la gouvernance d'entreprise existante, le portefeuille de projets, la gestion des risques, l'exploitation. Il faut savoir qui a déjà autorité sur quoi avant d'ajouter un comité.
Définir l'équipe et l'organisation. Rôles, responsabilités, rattachement, budget. C'est aussi là qu'on évalue la maturité actuelle de la pratique et qu'on écrit la cible.
Identifier et établir les principes d'architecture. Le sujet de la seconde moitié de ce billet.
Adapter le cadre TOGAF et les autres cadres retenus. Terminologie, phases que l'on fusionne ou allège, livrables que l'on renomme ou remplace, points d'articulation avec les méthodes projet. Le standard est conçu pour être adapté, et The Open Group le dit en toutes lettres.
Définir la stratégie d'outillage. Du tableur partagé à l'outil de modélisation avec dépôt, le choix dépend de la maturité visée, pas du catalogue des éditeurs. On fixe aussi le plan de déploiement de ces outils.
| Sortie de la phase | Ce qu'elle contient | Qui s'en sert ensuite |
|---|---|---|
| Modèle d'organisation pour l'architecture d'entreprise | Périmètre des organisations impactées, rôles, responsabilités, processus de gouvernance, contraintes et hypothèses | Toute l'équipe, dès la phase A |
| Cadre d'architecture adapté | Méthode (phases retenues, étapes modifiées), terminologie, contenu (livrables, artefacts), principes | Chaque cycle de l'ADM |
| Dépôt d'architecture initial | La structure, vide ou amorcée : paysage, standards, modèles de référence | Toutes les phases ; un billet de la série lui est consacré |
| Restitution des principes, objectifs et moteurs métier | Le contexte stratégique relu par l'équipe d'architecture | Phase A, pour les confirmer |
| Cadre de gouvernance d'architecture | Conseil, processus de conformité, gestion des dérogations | Phases G et H ; un billet de la série lui est consacré |
| Demande de travaux d'architecture (optionnelle) | Le déclencheur du premier cycle | Phase A |
Les six étapes livrent une organisation qui sait produire une architecture : son périmètre, ses règles, ses outils et son droit de décider. L'architecture elle-même viendra avec le premier cycle.
L'approche : sept questions avant le premier cycle
Avant de lancer une étude de ligne, la direction de la planification sait répondre à des questions simples : de quel réseau parle-t-on, qui le finance, à quelles normes il obéit, avec quelles administrations elle doit se coordonner, et de quoi elle est capable aujourd'hui.
Le standard formule l'approche de la phase préliminaire autour des mêmes questions.
Définir l'entreprise. L'étendue du mot : la société entière, une division, un écosystème avec ses fournisseurs. Cette décision fixe la portée de toutes les architectures à venir.
Identifier les moteurs et le contexte. La stratégie, la culture, les contraintes réglementaires, les attentes de la direction. Ce qui pousse l'organisation à vouloir une architecture, et ce qui va résister.
Définir les exigences du travail d'architecture. Ce que le métier attend de l'architecture : réduire le risque des programmes, maîtriser les coûts, assurer la conformité, aligner les investissements sur la stratégie. Ces attentes deviennent les critères de succès de la capacité.
Définir le cadre. TOGAF adapté, plus ce qu'on emprunte ailleurs. Le résultat est le cadre d'architecture adapté, l'une des sorties de la phase.
Définir les relations entre cadres de management. L'architecture dialogue avec quatre voisins : la gestion des capacités métier, les méthodes de gestion de portefeuille et de projets, les méthodes d'exploitation, les méthodes de développement de solutions. Chacun a son vocabulaire et ses jalons. Il faut écrire où ils se rencontrent.
Évaluer la maturité. Un modèle de maturité, une note honnête, un écart. On y revient en phase A avec l'évaluation de la maturité à la transformation.
Fixer la capacité désirée. Celle dont l'organisation a besoin et qu'elle peut financer, plutôt que la meilleure capacité imaginable.
La question décisive tient en deux temps : de quelle capacité d'architecture avons-nous besoin, et de laquelle disposons-nous aujourd'hui. Le cadre à adopter découle de l'écart, jamais l'inverse.
Les principes d'architecture
Sur Le Chemin de fer, une règle comme « plus aucun passage à niveau sur ligne nouvelle » ne décrit aucune ligne en particulier. Elle s'applique à toutes, elle survit aux ministres, et chaque étude de tracé la respecte sans qu'on la rediscute. C'est un principe.
TOGAF définit les principes comme des règles et lignes directrices générales, destinées à durer et rarement amendées, qui informent et soutiennent la manière dont une organisation remplit sa mission. Ils servent de base aux décisions, ils reflètent un consensus, et ils se rattachent aux objectifs métier.
Les principes d'architecture se rangent en catalogue, par domaine : principes métier, principes de données, principes d'applications, principes technologiques. Certains traversent les quatre.
Ils ne sortent pas de nulle part. Cinq sources les influencent : la mission, les plans et l'organisation de l'entreprise ; les initiatives stratégiques en cours ; les contraintes externes, marché et législation ; les systèmes et technologies déjà en place ; les tendances du secteur.
Qui les écrit ? Les architectes, l'architecte en chef en tête, avec les parties prenantes clés : la direction des systèmes d'information, les responsables métier, le conseil d'architecture. Qui les approuve ? Le conseil d'architecture, ou l'instance qui en tient lieu. Qui les change ? Personne seul : un processus d'amendement formel, avec traçabilité.
Trois traits complètent le portrait. Ils sont peu nombreux : le standard évoque un ordre de grandeur de dix à vingt, parce qu'au-delà ils se contredisent et personne ne les retient. Ils sont tournés vers l'avenir : ils décrivent la direction, pas l'existant. Ils sont portés par la direction : un principe que la direction ne défend pas en comité d'investissement reste un vœu.
Une bonne pratique se recommande. Un principe s'oppose à une décision contraire, et quelqu'un doit avoir le mandat de l'opposer.
La hiérarchie : entreprise, segment, architecture
Le ministère pose une règle nationale : la sécurité prime sur la vitesse. La direction régionale en déduit la sienne : aucun tronçon ne sera ouvert sans homologation complète. L'étude de ligne en déduit la sienne : signalisation de dernière génération sur toute la ligne nouvelle. Chaque règle précise la précédente. Aucune ne la contredit.
Les principes s'emboîtent de la même façon, et l'emboîtement suit les niveaux du paysage vus dans le billet sur les états et les partitions : stratégique, segment, capacité.
mission, valeurs, règles de décision du groupe"] --> S1["Principes de segment
la direction Finance"] E --> S2["Principes de segment
la direction Relation client"] S1 --> A1["Principes d'architecture
métier, données, applications, technologie"] S2 --> A2["Principes d'architecture
métier, données, applications, technologie"] A1 -.-> R["Règle d'emboîtement : un principe ne déborde jamais de celui du niveau supérieur"] A2 -.-> R classDef ent fill:#8a4d16,stroke:#5f5e5a,color:#f5f2ec classDef seg fill:#b5651d,stroke:#5f5e5a,color:#f5f2ec classDef arc fill:#d89253,stroke:#5f5e5a,color:#1a1a1a classDef regle fill:#ede9e1,stroke:#5f5e5a,color:#1a1a1a class E ent class S1,S2 seg class A1,A2 arc class R regle
Au sommet, les principes d'entreprise encadrent la façon dont l'organisation entière remplit sa mission. Ils ne parlent pas d'architecture. Ils parlent de décisions, de ressources et de comportements, et ils fondent tout le reste.
Au milieu, les principes de segment : une direction, un programme, un domaine métier décline les principes d'entreprise pour son terrain. Le segment Finance et le segment Relation client peuvent avoir des principes différents, pourvu qu'ils respectent le niveau au-dessus.
En bas, les principes d'architecture proprement dits gouvernent le travail d'architecture, et par ricochet la conception et l'implémentation des systèmes. TOGAF précise qu'ils incarnent l'esprit des principes d'entreprise existants.
La règle d'emboîtement tient en une phrase : un principe d'un niveau donné ne déborde jamais d'un principe du niveau supérieur. S'il le fait, le niveau supérieur tranche par le processus prévu : il amende son propre principe ou fait corriger le principe inférieur. La contradiction, elle, ne se tolère pas.
| Principes d'entreprise | Principes d'architecture | |
|---|---|---|
| Ce qu'ils gouvernent | La façon dont l'organisation remplit sa mission : décisions, ressources, comportements | Le travail d'architecture : développement, maintenance et usage de l'architecture, puis implémentation des systèmes |
| Qui les porte | La direction générale | Le conseil d'architecture et l'architecte en chef |
| Exemple | « Nous respectons les lois et règlements applicables » | « Chaque donnée a un propriétaire unique et identifié » |
| Horizon | La durée de la stratégie | La durée du cadre d'architecture, amendé quand la stratégie change |
| Relation entre les deux | Le cadre de référence | La déclinaison : ils incarnent l'esprit des principes d'entreprise, jamais l'inverse |
Quand deux principes se contredisent, ce n'est pas aux équipes de choisir au cas par cas. C'est au niveau supérieur de trancher, par écrit, et de corriger le catalogue.
Le gabarit : nom, énoncé, justification, implications
Sur le plan, « plus aucun passage à niveau sur ligne nouvelle » tient en une ligne. Dans le dossier, la règle occupe une page : pourquoi (les accidents aux passages à niveau), et ce que cela implique (un ouvrage d'art à chaque croisement, donc du budget et des délais).
TOGAF propose le même gabarit pour tout principe, en quatre zones.
Le nom et l'énoncé se lisent en dix secondes. La justification et les implications se lisent avant d'approuver, et se relisent chaque fois que quelqu'un demande une dérogation.
Voici le gabarit rempli sur l'exemple le plus consensuel du standard, la conformité à la loi, redit avec nos mots.
Dans le dépôt d'architecture, chaque principe devient une fiche avec un identifiant, un propriétaire, une date d'approbation et une version. C'est ce qui rend le processus d'amendement possible : on sait ce qu'on change, depuis quand, et qui en répond.
# Fiche de principe telle qu'elle vit dans le dépôt d'architecture
id: PR-DATA-03
nom: Conformité à la loi
domaine: données
niveau: architecture
enonce: >-
Les processus de gestion de l'information respectent les lois,
politiques et règlements applicables.
proprietaire: Conseil d'architecture
approuve_le: 2026-03-12
version: 1.2
revision_prevue: 2027-03
references:
- Règlement général sur la protection des données
- Politique interne de conservation des données
Un principe sans implications écrites n'a pas été approuvé, il a été applaudi. Les implications sont la partie qui coûte, donc la partie qui engage.
Cinq qualités, quatre usages
Un règlement ferroviaire se juge à l'usage. Le chef de chantier le comprend-il sans juriste ? Couvre-t-il la situation qu'il rencontre ce matin ? Deux articles se contredisent-ils ? Change-t-il à chaque ministre ?
Le standard retient cinq qualités pour un bon jeu de principes.
| Qualité | Ce que cela veut dire | Le test rapide |
|---|---|---|
| Compréhensible | L'intention est claire, la lecture sans ambiguïté, les violations se repèrent | Un chef de projet qui n'est pas architecte l'explique en une phrase |
| Robuste | Assez précis pour trancher une décision réelle et écrire une politique, y compris dans un cas complexe | Deux équipes face au même cas arrivent à la même conclusion |
| Complet | Couvre toutes les situations connues, aucun domaine sans règle | Chaque décision d'architecture de l'année passée se rattache à un principe |
| Cohérent | Aucun principe n'en contredit un autre, et l'interprétation reste équilibrée | Deux principes qui se tendent ont une règle d'arbitrage écrite |
| Stable | Durable, rarement amendé, mais doté d'une procédure d'amendement | La dernière modification est datée, motivée et tracée |
Et quatre usages, qui disent à quoi un jeu de principes sert concrètement.
Décider. Les principes forment le cadre de décision : entre deux options, celle qui respecte les principes gagne, et celle qui les viole doit justifier une dérogation.
Aligner. Ils relient la stratégie aux exigences : un principe de données se traduit en exigences fonctionnelles et non fonctionnelles pour chaque projet.
Gouverner. Ils fournissent les critères des revues de conformité : on évalue les portefeuilles existants et les projets à venir contre eux.
Faire culture. Ils donnent un langage commun entre métier et IT, et ils rendent visible la valeur de l'architecture : voilà pourquoi on a dit non, et voilà pourquoi on a dit oui.
Un jeu de principes qu'on ne cite jamais dans une décision n'a aucune des cinq qualités, quelle que soit la qualité de sa rédaction.
Les principes dans le cycle de l'ADM
Le règlement de la direction de la planification est écrit une fois. Mais chaque étude de ligne le relit, le précise pour son tracé, puis vérifie que les plans de voie, de signalisation et de caténaire le respectent.
Les principes suivent le même parcours dans l'ADM.
| Phase | Ce qu'on fait des principes | Résultat |
|---|---|---|
| Préliminaire | On les identifie, on les rédige dans le gabarit, on les fait approuver | Le catalogue de principes initial, dans le dépôt |
| A. Vision d'architecture | On les revoit, on les clarifie et on les complète pour le cycle qui s'ouvre ; on confirme les principes métier | Des principes confirmés dans l'énoncé des travaux et la vision |
| B, C, D | On les valide contre l'architecture cible de chaque domaine et on les aligne avec elle ; chaque écart devient une exigence ou une dérogation justifiée | Des architectures de domaine alignées, des dérogations tracées |
| E à G | On s'en sert comme critères de choix des solutions et de revue de conformité | Des non-conformités remontées à la gouvernance |
| H | Un changement d'environnement peut déclencher leur amendement | Un catalogue révisé, par le processus prévu |
Rien n'est figé. Un principe approuvé en préliminaire peut se révéler inapplicable en phase D, quand on découvre qu'aucune technologie disponible ne le satisfait. Le retour vers le conseil d'architecture fait partie du processus, pas de l'échec.
Les principes sont écrits en préliminaire, mais ils ne vivent qu'à partir de la phase A. Un principe qu'aucune phase ne relit ne gouverne rien.
Scénario B : le Clinger-Cohen Act et le principe « Cloud First »
Le cas réel de ce billet est une phase préliminaire menée à l'échelle d'un État, suivie d'un principe d'entreprise écrit noir sur blanc quinze ans plus tard.
1996 : créer la capacité
Le Clinger-Cohen Act est le nom courant de l'Information Technology Management Reform Act, promulgué le 10 février 1996 au sein de la loi d'autorisation de la défense américaine (Public Law 104-106). Il impose à chaque agence fédérale de désigner un directeur des systèmes d'information, responsable de développer, maintenir et faciliter la mise en œuvre d'une architecture des technologies de l'information intégrée pour son agence. Il instaure aussi un processus de planification et de contrôle des investissements informatiques, sous la supervision de l'Office of Management and Budget.
Lu avec la grille de ce billet, c'est une phase préliminaire : un périmètre (chaque agence), un responsable et une équipe (le CIO), une gouvernance (l'OMB et le processus d'investissement), et l'obligation de tenir une architecture. Le cadre est venu ensuite : le CIO Council a publié en septembre 1999 le Federal Enterprise Architecture Framework pour outiller cette obligation.
2011 : un principe d'entreprise, gabarit compris
Le 8 février 2011, Vivek Kundra, directeur des systèmes d'information fédéral, publie la Federal Cloud Computing Strategy, annoncée deux mois plus tôt dans son plan en vingt-cinq points de réforme de l'informatique fédérale. Son cœur est un principe baptisé « Cloud First », qui se lit presque dans le gabarit de TOGAF.
Énoncé : les agences adoptent par défaut une solution cloud dès qu'une option cloud sûre, fiable et économique existe.
Justification : la stratégie décrit un parc fédéral sous-utilisé, des centres de données qui se sont multipliés, des délais de déploiement longs, et attend du cloud de l'efficacité, de l'agilité et de l'innovation. Le document estime lui-même qu'environ 20 des 80 milliards de dollars de dépenses informatiques fédérales constituent un périmètre potentiel de migration. C'est une estimation de périmètre, pas un bilan d'économies, et ce billet n'en avance aucun.
Implications : chaque agence devait identifier trois services à migrer, en déplacer un sous douze mois et les deux autres sous dix-huit ; toute nouvelle dépense informatique devait d'abord évaluer une option cloud ; la sécurité appelait un processus d'autorisation commun, qui a pris la forme du programme FedRAMP, créé par un mémorandum de l'OMB en décembre 2011.
Un principe qui gouverne, puis qui s'amende
Pendant la décennie suivante, « Cloud First » a servi de critère d'arbitrage dans les revues d'investissement : « avez-vous évalué une option cloud ? » est devenu une case du dossier plutôt qu'une opinion. C'est l'usage « décider » et l'usage « gouverner » de la section précédente, à l'échelle d'un gouvernement.
En juin 2019, l'OMB a publié une stratégie révisée, « Cloud Smart », qui conserve l'orientation vers le cloud mais remplace le réflexe par défaut par une évaluation sur trois axes : la sécurité, les achats et les compétences. Un principe d'entreprise amendé par un processus formel, huit ans après, parce que le contexte avait changé. C'est le mot « stable » du tableau des qualités, pas le mot « figé ».
Une loi de 1996 a créé la capacité. Un document de 2011 a écrit le principe. Chaque arbitrage d'investissement de la décennie l'a appliqué, puis le processus l'a amendé. Voilà à quoi ressemble un principe qui tient.
Points clés
- La phase préliminaire ne produit aucune architecture : elle crée la capacité d'en produire (périmètre, gouvernance, équipe, principes, cadre adapté, outils), et on n'y revient que quand cette capacité doit changer.
- Ses six étapes livrent un modèle d'organisation, un cadre TOGAF adapté, un dépôt initial, un cadre de gouvernance et le catalogue de principes ; la demande de travaux d'architecture qui ouvre la phase A en est une sortie possible.
- Un principe s'écrit dans un gabarit en quatre zones (nom, énoncé, justification, implications), s'emboîte dans une hiérarchie entreprise, segment, architecture, et ne déborde jamais du niveau supérieur.
- Un bon jeu de principes est compréhensible, robuste, complet, cohérent et stable ; il compte une dizaine à une vingtaine d'entrées, portées par la direction et amendées par un processus tracé.
- Identifiés en préliminaire, revus en A, validés en B, C et D : le Clinger-Cohen Act (1996) puis le principe « Cloud First » (2011), amendé en « Cloud Smart » (2019), montrent ce parcours grandeur nature.
Dans la série
Palier 1 : Tracer la ligne. Domaine : Cadrage.
- Précédent : L'ADM de TOGAF : dix phases, artefacts, livrables, points de vue
- Suivant : Phase A : vision d'architecture, demande et énoncé des travaux
- Vue d'ensemble : Architecture d'entreprise : par où commencer
Pour aller plus loin
- Le TOGAF Standard, 10e édition, publié par The Open Group : la partie ADM pour la phase préliminaire, la partie ADM Techniques pour le chapitre sur les principes d'architecture
- ISO/IEC/IEEE 42010, pour les définitions d'architecture, de partie prenante et de préoccupation que TOGAF reprend
- Information Technology Management Reform Act of 1996 (Clinger-Cohen Act), Public Law 104-106, Division E, 10 février 1996 : texte intégral de la loi sur GovInfo (U.S. Government Publishing Office)
- Federal Cloud Computing Strategy, Vivek Kundra, U.S. Chief Information Officer, 8 février 2011 : document public archivé (PDF) sur obamawhitehouse.archives.gov
- Federal Cloud Computing Strategy « Cloud Smart », Office of Management and Budget, juin 2019 : document public publié sur cloud.cio.gov
- L'ADM de TOGAF : dix phases, artefacts, livrables, points de vue, pour situer la phase préliminaire dans le cycle entier
- Gouvernance d'architecture : conseil, conformité et capacité, pour la suite de la capacité créée ici : le conseil, les revues de conformité, les dérogations