Comment les petites équipes font de l'architecture d'entreprise (et ce qu'on peut en apprendre)

Quand on parle d'architecture d'entreprise, on pense presque automatiquement aux grands groupes. Des DSI de plusieurs centaines de personnes, des centaines d'applications au catalogue, des schémas directeurs à cinq ans, des comités d'architecture mensuels.

Et c'est normal : l'EA en tant que discipline s'est construite dans ce contexte. TOGAF, ArchiMate, Zachman, tout ça a été pensé pour des organisations de grande taille avec une complexité proportionnelle.

Mais il y a un angle mort dans cette vision. Parce que les entreprises de 20, 50 ou 200 personnes ont aussi un système d'information. Elles ont aussi des applications, des flux de données, des dépendances, des choix techniques à faire. Et elles font de l'architecture, souvent sans appeler ça comme ça.

On s'est intéressés à la façon dont ces petites structures abordent le sujet. Et on a trouvé des choses plutôt inspirantes, y compris pour les grandes organisations.

L'EA sans le titre

Dans une boîte de 50 personnes, il n'y a généralement pas d'architecte d'entreprise. Il n'y a pas de comité d'architecture non plus. Parfois il n'y a même pas de DSI au sens classique.

Et pourtant, quelqu'un sait comment le SI est câblé. C'est souvent le CTO, parfois un lead dev, parfois le CEO technique qui a tout monté au départ. Cette personne a une carte mentale du système : quelles applis sont connectées à quoi, où vivent les données, quel workflow passe par quel outil.

Ce qui est intéressant, c'est que cette carte mentale est souvent assez juste. Pas exhaustive, pas formalisée, mais juste. Parce que dans une petite équipe, la personne qui connaît le système est aussi celle qui l'utilise, qui le fait évoluer, qui répare quand ça casse. Le décalage entre la carte et le territoire est faible, parce que les deux sont tenus par les mêmes mains.

Le problème, évidemment, c'est que cette carte vit dans une seule tête. Et quand l'équipe grandit, quand cette personne part en vacances, change de poste ou quitte l'entreprise, la carte part avec elle.

Le pragmatisme par défaut

Ce qui nous frappe souvent chez les petites équipes, c'est leur rapport très pragmatique à l'architecture.

Elles ne partent pas d'un framework. Elles partent d'un problème. "On ne sait plus quelles données sont dans quel outil." "On a changé de CRM et on a cassé trois intégrations qu'on avait oubliées." "Le nouveau dev met trois semaines à comprendre comment les choses sont connectées."

La réponse est rarement un projet de cartographie formelle. C'est plutôt un schéma sur un tableau blanc, un document Notion avec la liste des outils et leurs connexions, ou un diagramme Draw.io fait un dimanche soir par le CTO qui en avait marre de réexpliquer la même chose.

C'est incomplet. C'est informel. Et c'est souvent suffisant pour le stade où en est l'entreprise.

Il y a une leçon là-dedans pour les grandes organisations : l'EA la plus utile est celle qui répond à un problème concret, pas celle qui remplit les cases d'un framework. On peut faire beaucoup de choses utiles avec une cartographie imparfaite mais orientée vers une question précise.

La connaissance partagée, naturellement

Dans une équipe de 20 personnes, tout le monde sait à peu près ce que font les autres. Le commercial sait quel outil utilise le support. Le développeur sait quel SaaS a été souscrit par le marketing. La connaissance du SI est distribuée naturellement par la proximité.

Les réunions d'architecture n'existent pas en tant que telles, mais leurs équivalents sont partout : le standup du matin, le channel Slack où quelqu'un demande "c'est quoi déjà le lien entre Hubspot et notre outil de facturation ?", le onboarding du nouveau où on fait le tour des outils.

Ce qui se passe quand l'entreprise grandit, c'est que cette connaissance distribuée se fragmente. À 50 personnes, le commercial ne sait plus ce qu'utilise le support. À 100 personnes, il y a des outils dont certains ignorent l'existence. À 200 personnes, personne n'a la vision complète.

C'est souvent à ce moment-là que le besoin d'EA se fait sentir, même si personne ne le formule comme ça. Ce n'est pas "on a besoin d'un architecte d'entreprise". C'est "on ne sait plus comment notre SI tient ensemble".

Ce que les grandes organisations peuvent en tirer

On ne va pas idéaliser les petites équipes. Elles ont leurs propres problèmes : la dépendance à une seule personne, le manque de documentation, la dette technique qui s'accumule discrètement parce que tout le monde est trop occupé à livrer.

Mais il y a quelques principes qui méritent d'être retenus.

Partir du problème, pas du framework. Les petites équipes ne cartographient pas pour cartographier. Elles le font parce qu'elles ont un problème à résoudre : une migration à préparer, un onboarding à simplifier, un incident à comprendre. Dans les grandes organisations, on oublie parfois cette logique. Le framework devient la fin, pas le moyen.

Garder la carte lisible par tous. Quand le CTO d'une startup dessine le SI sur un tableau blanc, tout le monde dans la salle comprend. Personne ne demande "c'est quoi ce symbole ?". Il n'y a pas de légende de trois pages. La lisibilité est naturelle parce que le public est dans la pièce. C'est un standard que les grandes organisations pourraient viser plus souvent : est-ce que ma cartographie est compréhensible par quelqu'un qui n'est pas architecte ?

Accepter l'imperfection utile. Une petite équipe ne passera jamais six mois à produire une cartographie exhaustive. Elle produira quelque chose d'incomplet mais d'utile, et elle l'améliorera au fur et à mesure. Il y a une sagesse là-dedans : mieux vaut une carte à 70% qui vit et qui sert, qu'une carte à 100% qui dort dans un drive.

Maintenir la proximité avec le terrain. Dans une petite équipe, celui qui cartographie est aussi celui qui opère. Il n'y a pas de décalage entre la théorie et la pratique. Dans les grandes organisations, l'architecte est souvent éloigné du terrain. Trouver des moyens de rapprocher l'architecture du quotidien des équipes, c'est probablement l'un des enjeux les plus importants de l'EA moderne.

Le moment de bascule

Il y a un moment dans la vie d'une entreprise en croissance où les pratiques informelles ne suffisent plus. C'est rarement un moment net. C'est plutôt une accumulation : un incident qu'on met trois jours à diagnostiquer parce que personne ne connaissait une dépendance, une migration qui dérape parce qu'on avait oublié un flux, un audit de sécurité qui révèle des outils dont personne n'avait la liste complète.

C'est le moment où l'EA informelle doit se structurer un peu. Pas forcément devenir une discipline lourde avec des rôles dédiés et des comités mensuels. Juste passer de la carte mentale à quelque chose de partagé, accessible et maintenable.

Ce passage est délicat. Beaucoup d'entreprises en croissance font l'erreur de sauter directement aux outils et aux process des grands groupes. Elles achètent un outil d'EA enterprise, imposent un framework, et se retrouvent avec quelque chose de trop lourd pour leur taille et leur culture.

L'idéal, c'est probablement de garder l'esprit des pratiques informelles (pragmatisme, lisibilité, orientation problème) tout en ajoutant la structure minimale nécessaire pour que la connaissance ne dépende plus d'une seule personne.

C'est un peu notre terrain de jeu chez Boldo

Cette transition, entre l'EA informelle et la structuration, c'est un sujet qui nous parle beaucoup. Parce qu'on pense qu'il manque quelque chose entre le tableau blanc et l'outil d'EA enterprise classique.

On essaie de construire Boldo pour qu'il soit utile dès les premières étapes : suffisamment simple pour remplacer le schéma Notion du CTO, suffisamment structuré pour accompagner la croissance, suffisamment ouvert pour que toute l'équipe puisse y contribuer.

Simple au départ. Commencer avec quelques composants et quelques liens, comme on le ferait sur un tableau blanc. Pas de formation préalable, pas de framework imposé.

Structuré quand ça compte. Au fur et à mesure que le SI se complexifie, ajouter des couches : vues métier, analyse de dépendances, connexion aux données réelles.

Partagé par design. Que la carte soit lisible et accessible à toute l'équipe, pas réservée à la personne qui l'a créée.

L'EA n'a pas besoin d'être lourde pour être utile. Parfois, le mieux qu'on puisse faire, c'est de garder l'esprit de la petite équipe dans un outil qui grandit avec vous.