Préface

Quelques années de missions de conseil et de mise en œuvre suffisent pour observer un schéma récurrent : l'expression « architecture SI » recouvre, selon les interlocuteurs, des réalités très différentes. Pour les uns, c'est un schéma de serveurs ; pour d'autres, la liste des logiciels installés ; pour d'autres encore, le travail du développeur. Cette confusion n'est pas anodine. Elle conduit des organisations à engager des budgets considérables sur des fondations mal posées.

Trois malentendus reviennent systématiquement. Le premier consiste à partir de la solution — un outil, une technologie à la mode, aujourd'hui « une intelligence artificielle » — avant d'avoir formulé le besoin métier qu'elle est censée servir. Le deuxième confond l'architecture du système d'information, qui orchestre l'ensemble des applications d'une organisation, avec l'architecture logicielle, qui décrit la structure interne d'une seule application. Le troisième mélange la conception, qui définit la cible, et l'exploitation, qui fait tourner le système au quotidien.

Ce document a été écrit pour dissiper ces malentendus. Il ne prétend pas remplacer les ouvrages de référence ni les normes qu'il cite : il les met en perspective et propose une démarche praticable, en distinguant clairement ce qui relève de l'architecture SI de ce qui n'en relève pas. Il s'adresse autant au décideur qui veut comprendre ce qu'il finance qu'au praticien qui veut structurer son travail.

Le fil conducteur tient en une conviction, posée d'emblée et défendue tout au long du document.

Mattieu Pottier — MP-i · Mattieu Pottier Indépendant

---

Introduction

Concevoir un système d'information revient à organiser la manière dont une organisation produit, échange et exploite son information pour servir ses objectifs. L'architecture SI est la discipline qui rend cette organisation cohérente, durable et maîtrisée — plutôt que subie.

Pourquoi structurer son SI est stratégique

Faute d'architecture, un système d'information se construit par accrétion : on ajoute une application ici, une intégration là, un correctif ailleurs. Au bout de quelques années, plus personne ne sait précisément qui parle à qui, quelle donnée fait référence, ni pourquoi tel choix a été fait. Les conséquences sont mesurables : dette technique, dépendances non maîtrisées, doublons fonctionnels, coûts d'exploitation qui dérivent.

L'architecture SI inverse cette logique. Elle aligne le système d'information sur la stratégie métier, arbitre les choix avant qu'ils ne deviennent irréversibles, et rend les décisions traçables. Un système mal architecturé n'est pas seulement plus difficile à faire évoluer : il coûte durablement plus cher à exploiter.

Une réserve, toutefois, vaut avertissement. Selon les analyses du cabinet Gartner, une part importante des livrables d'architecture — de l'ordre du tiers — n'est jamais réutilisée par le reste de l'organisation. L'architecture n'a de valeur que si elle est actionnable et reliée aux décisions réelles. Un document d'architecture qui ne sert à personne n'est pas de l'architecture : c'est du formalisme.

Le périmètre de ce document

Ce livre blanc couvre les définitions et le périmètre de l'architecture SI, les cadres et normes de référence, les langages de modélisation, la démarche de conception phase par phase, les mécanismes d'itération et de gouvernance, ainsi que la méthode de sélection des outils et des logiciels.

Il ne constitue pas un manuel exhaustif d'un cadre particulier, n'impose aucune technologie, et n'aborde ni la gestion de projet ni la gestion des services au quotidien, qui relèvent d'autres disciplines. Ces frontières sont assumées : elles font partie de la clarification que ce document cherche à apporter.

Profils de lecture

---

Partie 1 — Qu'est-ce qu'une architecture de système d'information ?

Avant toute démarche, il faut s'entendre sur les termes. Cette partie pose les définitions, distingue les niveaux d'architecture que l'on confond souvent, et présente la manière dont une architecture se décrit.

1.1 Définition et finalité

La finalité de l'architecture SI n'est pas de produire de beaux schémas, mais de prendre et de tracer de bonnes décisions structurantes : quels processus outiller, avec quelles applications, autour de quelles données, sur quelle infrastructure, et selon quels principes. Tout le reste en découle.

1.2 Architecture d'entreprise, architecture SI, architecture logicielle

La plupart des cadres invoqués dans ce domaine — TOGAF, Zachman — sont des cadres d'architecture d'entreprise : un périmètre plus large que le seul système d'information, puisqu'ils incluent la stratégie et l'organisation. L'architecture SI en est un sous-ensemble, et l'architecture logicielle, un cran en dessous encore, ne concerne que la structure interne d'une application. Confondre ces trois niveaux est la première source de malentendus.

1.3 Les domaines d'architecture

L'architecture SI se décline classiquement en plusieurs domaines. Le référentiel TOGAF en distingue quatre, désignés par l'acronyme BDAT : Business, Data, Application, Technology.

Ce découpage n'est pas universel : il varie selon le référentiel. L'urbanisation française distingue traditionnellement une couche fonctionnelle de la couche applicative, et traite la donnée de façon transverse. Le langage ArchiMate, lui, ne retient que trois couches de cœur — métier, applicative et technologique. Retenir un modèle revient donc moins à mémoriser un nombre de couches qu'à comprendre la logique de séparation : ce que fait l'organisation, ce qu'elle connaît, avec quoi elle l'outille, et sur quoi cela tourne. Dans la suite de ce document, les termes « domaine » et « couche » sont employés indifféremment.

1.4 La sécurité, une préoccupation transverse

Il serait tentant de ranger la sécurité dans la seule couche technique. C'est une erreur. La sécurité traverse les quatre domaines : elle concerne les droits métier, la confidentialité des données, le cloisonnement des applications et le durcissement de l'infrastructure. Les versions récentes des cadres de référence l'ont reconnu en élevant la sécurité au rang de préoccupation de premier plan.

1.5 Décrire une architecture : parties prenantes, points de vue, vues

La norme ISO/IEC/IEEE 42010:2022 définit ce qu'est une description d'architecture. Sa logique est essentielle à comprendre, car elle structure tout livrable sérieux.

Autrement dit, il n'existe pas de représentation unique et universelle d'une architecture : il existe autant de vues que de préoccupations à adresser. C'est pourquoi un projet d'architecture produit plusieurs diagrammes, et non un seul « grand schéma ».

1.6 Ce qui relève de l'architecture SI, ce qui n'en relève pas

---

Partie 2 — Les cadres et les normes de référence

On ne conçoit pas une architecture à partir d'une page blanche : des cadres méthodologiques et des normes internationales structurent la démarche. Encore faut-il savoir lequel mobiliser, et à quelle échelle.

2.1 Les cadres d'architecture d'entreprise

Le cœur de TOGAF est l'ADM (Architecture Development Method), un cycle de phases qui irrigue toute la suite de ce document. La démarche présentée en Partie 4 en est une transposition simplifiée, calibrée pour des organisations de taille modeste.

2.2 Les normes mobilisables

La norme ISO/IEC 25010 mérite une attention particulière : ses neuf caractéristiques — adéquation fonctionnelle, performance, compatibilité, capacité d'interaction, fiabilité, sécurité, maintenabilité, flexibilité et sûreté — constituent une liste de contrôle directement utilisable pour cadrer les exigences non fonctionnelles d'un projet et, plus loin, pour évaluer des solutions.

2.3 Quel cadre pour quelle échelle

---

Partie 3 — Modéliser : langages et diagrammes de flux

Modéliser, c'est produire les vues évoquées en Partie 1. Encore faut-il employer la bonne notation pour le bon objet — un point particulièrement source de confusion autour de l'expression « diagramme de flux ».

3.1 « Diagramme de flux » : un terme, plusieurs réalités

« Diagramme de flux » ne désigne pas une notation unique mais une famille d'objets distincts, qui n'appartiennent pas à la même couche et ne s'expriment pas avec la même notation.

Une précision s'impose sur le DFD (Data Flow Diagram). Cette notation, issue de l'analyse structurée des années 1970-1980, reste pédagogiquement utile pour expliquer la circulation de la donnée, mais elle n'est plus un standard vivant. En 2026, les flux de données se documentent plutôt via les diagrammes d'échange applicatif, le langage ArchiMate ou les outils de traçabilité de la donnée.

3.2 Les langages de modélisation

3.3 Les outils

Ces langages s'appuient sur des outils éprouvés et largement gratuits : Archi pour ArchiMate, Structurizr ou PlantUML pour le modèle C4, ou encore des éditeurs génériques comme draw.io pour les schémas libres. L'outil importe moins que la rigueur de la notation : un diagramme cohérent vaut mieux qu'un bel outil mal employé.

3.4 Où se place chaque modèle

---

Partie 4 — La démarche : par quoi on commence, par quoi on finit

C'est le cœur du sujet. Une architecture se conçoit selon une séquence ordonnée, encadrée par deux activités transverses, et débouchant sur un plan actionnable.

4.1 Le principe fondateur : le métier avant la technologie

4.2 Deux activités transverses à tout le cycle

Avant même la première phase, deux activités encadrent l'ensemble du cycle et ne s'arrêtent jamais.

4.3 Le cycle en phases

4.4 L'analyse d'écart, moteur de la trajectoire

Entre l'état des lieux et la cible, un mécanisme produit la trajectoire : l'analyse d'écart (gap analysis). Elle consiste à comparer, domaine par domaine, ce qui existe et ce qui est visé, puis à transformer chaque écart en action. C'est cette analyse, et non la cible elle-même, qui rend le projet exécutable.

4.5 Détail par phase

À chaque phase, la sécurité est traitée dès la conception et non rajoutée ensuite : exigences de sécurité dès le cadrage, intégration aux quatre domaines en phase cible, critères de sécurité dans la sélection technique.

4.6 Le début et la fin, explicitement

---

Partie 5 — Itérer et gouverner

Une architecture n'est pas un document que l'on produit une fois pour le classer. C'est un actif vivant qui se gouverne et se réajuste.

5.1 Une cible et une trajectoire, pas un livrable figé

Concevoir une architecture, ce n'est pas figer un état définitif, mais tenir simultanément une cible — vers où l'on va — et une trajectoire — comment on y avance, par incréments. La cible se réajuste à mesure que le métier évolue ; la trajectoire se réordonne selon les priorités et les moyens. Une architecture qui prétend tout figer d'un coup est une architecture qui sera obsolète avant d'être mise en œuvre.

5.2 Le raffinement par paliers et la gouvernance d'architecture

Au sein d'un projet, on procède du macro vers le détail : une vision d'ensemble d'abord, puis une descente progressive, couche par couche, validée à chaque jalon. Cette validation est le rôle de la gouvernance d'architecture — une instance, même légère dans une petite structure, qui arbitre les écarts par rapport aux principes et autorise le passage d'un palier au suivant.

5.3 Le rôle de l'architecte et le référentiel

L'architecture est portée par un rôle — l'architecte — qui fait l'interface entre les parties prenantes métier et les équipes techniques. Son travail ne vaut que s'il est consigné dans un référentiel maintenu : la cartographie du SI et les décisions prises doivent rester accessibles et à jour. Un référentiel laissé à l'abandon vaut moins qu'aucun référentiel, car il induit en erreur.

5.4 L'architecture évolutive

Les approches modernes proposent de rendre l'évolutivité mesurable, au moyen de fonctions d'aptitude (fitness functions) — des contrôles automatisés qui vérifient en continu que l'architecture respecte ses propriétés clés (performance, couplage, sécurité). Couplées à des décisions tracées et régulièrement revues, elles permettent à l'architecture de se réajuster sans dériver.

5.5 Les trois échelles d'itération

---

Partie 6 — Choisir les outils et les logiciels

Les choix techniques arrivent tard dans la démarche, et ce n'est pas un hasard : ils découlent de la cible et des exigences, jamais l'inverse. Encore faut-il les conduire avec méthode.

6.1 La méthode de décision rationnelle

6.2 Évaluer un logiciel open source : QSOS

Un logiciel libre reste un logiciel : il s'évalue. Mais il appelle des questions spécifiques que QSOS formalise — la pérennité de la structure porteuse, l'activité de la communauté, le type de licence, la qualité des développements. La méthode procède en définissant un référentiel de critères, en évaluant les candidats sur ces critères, en qualifiant le besoin par pondération, puis en sélectionnant. Recourir à une grille reconnue plutôt qu'à une impression personnelle est ce qui distingue un choix défendable d'un pari.

6.3 Tracer la décision : l'ADR

---

Guide décisionnel

Cette section condense la démarche en trois aides à la décision : un arbre pour choisir le niveau de formalisme, une matrice pour choisir un cadre, et des scénarios types.

Arbre de décision

Matrice cadre × contexte

Scénarios types

---

Tendances et horizon 2026

La discipline évolue. Les tendances ci-dessous, observées chez les responsables d'architecture en 2026, méritent d'être surveillées — non pour les suivre aveuglément, mais pour anticiper leur impact.

---

Conclusion

Trois idées traversent ce document. La première : une architecture SI part du besoin métier et de l'existant, jamais d'une technologie choisie d'avance. La deuxième : elle se décline en domaines — métier, données, applicatif, technique — traversés par la sécurité, et se décrit non par un schéma unique mais par un ensemble de vues adressant les préoccupations des parties prenantes. La troisième : elle se conçoit selon une séquence claire, du cadrage à la trajectoire, et se maintient vivante par itérations.

La valeur d'une architecture ne tient pas à l'épaisseur de sa documentation, mais à sa capacité à éclairer des décisions et à rester actionnable. Le cadre se picore, le formalisme s'adapte à l'échelle, et chaque décision se trace pour rester révisable. C'est à cette condition qu'un système d'information devient un actif maîtrisé plutôt qu'une dette qui s'accumule.

---

Références et ressources

---

Glossaire

Architecture d'entreprise

Discipline englobant la stratégie, le métier et le système d'information d'une organisation. L'architecture SI en est un sous-ensemble.

Architecture SI

Organisation d'ensemble reliant les processus métier aux applications, aux données et à l'infrastructure.

Urbanisation

Approche, d'origine française, qui structure le SI par analogie avec l'aménagement d'une ville (zones, quartiers, îlots, blocs).

Capacité métier

Aptitude d'une organisation à réaliser une activité, indépendamment de la manière dont elle est outillée.

Point de vue / vue

Manière convenue de représenter une architecture pour adresser une préoccupation (point de vue) ; le résultat concret de son application (vue).

Principe d'architecture

Règle directrice posée en amont, qui cadre l'ensemble des décisions ultérieures.

ADM

Architecture Development Method — le cycle de conception en phases au cœur de TOGAF.

ADR

Architecture Decision Record — fiche traçant une décision d'architecture, ses alternatives et ses conséquences.

Analyse d'écart

Comparaison entre l'existant et la cible, dont découle la trajectoire de transformation.

BPMN

Business Process Model and Notation — notation standard de modélisation des processus métier.

C4

Modèle de documentation d'architecture logicielle à quatre niveaux : contexte, conteneurs, composants, code.

ArchiMate

Langage de modélisation d'architecture d'entreprise, aligné sur TOGAF.

Merise

Méthode française de modélisation des données par niveaux conceptuel, logique et physique.

TCO

Total Cost of Ownership — coût total de possession d'une solution sur son cycle de vie, au-delà du prix d'acquisition.

Fonction d'aptitude

Contrôle automatisé (fitness function) vérifiant en continu qu'une architecture respecte une propriété clé.

---

Historique des révisions

---

À propos de l'auteur

MP-i — Mattieu Pottier Indépendant