Architecte informatique : un super-développeur ?

Introduction

J’arrive sur un projet.

On me présente comme « l’architecte », avec une solennité proche de l’invocation d’un personnage légendaire.
Côté client, c’est le soulagement : “Ah, ENFIN quelqu’un qui va nous sauver.”
Côté équipe, c’est plus mitigé. Les tech leads sont dubitatifs. « Un Archi ? mais y’en a pas besoin, on s’en sort bien, et puis c’est moi l’archi ! ».
Et les devs seniors, eux, se demandent si je vais leur piquer leur terrain de jeu ou leur expliquer la vie.

Dans les faits, je me retrouve à devoir faire beaucoup de choses, dont beaucoup laissées de côté par les équipes.
La doc? Inutile, y a JeanMi qui t’explique. Ce qu’il faut installer ? Met Eclipse, ca ira. Le code? Il est sur git, et on a aussi un svn, et puis tu trouveras le reste sur le serveur…
Expliquer la méthode agile au chef de projet, clarifier le besoin fonctionnel au PO, expliquer que oui, il faut des spécifications écrites, les US sont un extrait des spécs…
Résoudre des bugs de performance, revoir des schémas d’architecture obsolètes depuis 10 ans, et parfois… recoder un bout de script bash qui traînait depuis 2009.

Bref, souvent, il faut mettre de la méthode dans tout cela.
Alors pourquoi les architectes sont-ils souvent pris pour des supers développeurs avec option “sauveur du monde” ?
Pourquoi cette attente démesurée d’un côté, et cette défiance tenace de l’autre ?
On en parle ici.

L’architecte, ce développeur qu’on a trop laissé traîner près des post-it

Soyons honnêtes : la plupart d’entre nous, architectes, on a commencé en tant que développeurs.
On a aimé coder. Beaucoup. Parfois trop.
Et un jour, on a eu cette drôle d’idée : « et si on prenait un peu de recul ? »

On a commencé à poser des questions qui fâchent.
– Pourquoi on multiplie les microservices alors qu’on a trois développeurs ?
– Pourquoi on stocke ça dans un fichier .conf ET dans PostgreSQL ?
– Pourquoi l’authentification passe par une API qui appelle une autre API, qui appelle une base Excel partagée ?
Et bim. On devient architecte. Et là, surprise : plus personne ne sait trop ce qu’on fait.
Mais tout le monde attend qu’on le fasse.
Y compris les trucs qui n’ont rien à voir avec l’architecture.

La perception du client : l’architecte, ce « niveau 42 »

Pour le client, l’architecte est LE niveau ultime.
Celui qui sait tout, voit tout, peut tout.
Un peu comme si un développeur fullstack, un expert cybersécurité, un urbaniste, un coach agile et un devOps avaient fusionné pour devenir un guerrier Saiyan.

Du coup, quand il y a un problème, c’est vers toi qu’on se tourne.
– Le site est lent ? Appelle l’architecte.
– L’authentification ne fonctionne pas ? Appelle l’architecte.
– La cuisine de l’open space est fermée ? On ne sait jamais, appelle l’architecte.

Tu te retrouves à recoller les morceaux d’un besoin mal formulé, d’un sprint mal démarré, ou d’un composant open source mal compris.
Et à sourire poliment quand on te dit :

“T’as qu’à faire une petite doc rapide, ça te prendra 5 minutes non ?”
(Non.)

Tech leads et seniors : entre respect, défiance et syndrome de territoire

Et là… on arrive sur le terrain miné.

Tu pensais être accueilli comme un renfort ?
Tu es vu parfois comme un inspecteur des travaux finis.

Il y a ce tech lead qui fait tourner le projet à bout de bras depuis des mois.
Il t’analyse, comme s’il évaluait si tu allais lui piquer son rôle ou lui imposer un refacto complet.
Il t’écoute poliment. Et termine souvent par :

“Ouais, enfin… on fait déjà comme ça, ça marche.”

Et ce développeur senior, brillant mais épuisé, qui se demande si tu vas vraiment l’aider… ou juste multiplier les réunions pour parler d’une “vision cible” pendant qu’il corrige des bugs en prod.

Alors, il faut gagner leur confiance.
Montrer que tu ne viens pas pour remplacer, mais pour structurer, accompagner, anticiper.
Et souvent, il faut commencer par mettre les mains dans le cambouis. Oui, même si ce n’est plus censé être ton rôle.

Entre développeurs et managers : l’architecte flottant

L’architecte est un être étrange, ni tout à fait tech, ni tout à fait chef de projet.
Tu n’es plus censé coder, mais on t’en demande encore et bien.
Tu ne diriges pas le projet, mais tu es censé le faire réussir.
Tu es à la fois :

• le confident du Product Owner (“Dis, t’as bien compris ce que veut le métier, toi ?”),
• le coach du dev junior (“Alors ici, t’as une boucle infinie, mais sympa l’intention”),
• le paratonnerre du chef de projet (“Tu peux l’annoncer toi à la direction, que ce planning est intenable ?”).

Et bien sûr, tu es responsable de l’architecture globale.
Même si personne n’a pris le temps de te dire ce qu’elle devait faire, ni comment elle devait s’insérer dans l’existant.

L’architecte n’est pas omniscient

Alors posons les choses.

Non, je ne connais pas toutes les options de configuration de Keycloak.
Non, je n’ai pas en tête les limites de mémoire exactes d’un pod Kubernetes sous forte charge réseau.
Non, je ne peux pas décider seul de la stratégie de découpage fonctionnel si le métier ne sait pas ce qu’il veut.

Mais j’écoute, j’analyse, je pose des questions, et je crée du lien.
Et ça, c’est souvent ce qui manque le plus dans les projets.

Conclusion : et si l’architecte, c’était juste un facilitateur de complexité ?

On nous prend pour des super-dévs.
On nous craint comme des inspecteurs.
Mais au fond, on est juste là pour rendre les choses compréhensibles, pour éviter les impasses et pour faire le pont entre des mondes qui ne se parlent plus.

On est des généralistes avec de la bouteille, des passeurs, des détecteurs de zones floues.
Mais nous en sommes certainement pas des magiciens.

Nous sommes juste des architectes et c’est déjà pas mal.