Le métier d'architecte : rôle, mindset et influence sans autorité

Le maître d'œuvre ne commande personne

Sur Le Chantier, l'architecte arrive le matin avec ses plans sous le bras. Le maçon ne travaille pas pour lui. L'électricien non plus, ni le plombier, ni le grutier. Chacun a son entreprise, son planning et sa marge à défendre.

Pourtant, si la trémie de l'ascenseur est décalée de vingt centimètres, c'est lui qu'on appelle. Si le bâtiment ne passe pas la commission de sécurité, c'est son nom qui figure en tête du dossier.

C'est exactement la position de l'architecte logiciel. Il ne signe l'entretien annuel de personne et n'attribue pas les tickets. Sur les augmentations, il n'a aucune prise. Et le jour où le système s'écroule sous la charge, personne ne va chercher le développeur qui a écrit la boucle.

L'architecte porte une responsabilité qui dépasse largement son autorité. Le métier consiste à combler cet écart autrement que par la hiérarchie.

C'est ce qui distingue le poste de « développeur senior avec un meilleur titre ». Le développeur sait ce qui peut être fait. L'architecte doit savoir ce qui devrait l'être, et ce n'est pas la même question.

Trois volets tiennent le rôle. On les prendra dans cet ordre, du plus visible au plus difficile, une fois réglée la question des intitulés de poste.

Trois architectes, trois échelles

Sur un grand programme immobilier, trois métiers portent le mot « plan » sans faire le même travail. L'ingénieur structure et fluides s'occupe de ce qui tient debout et de ce qui circule. L'architecte dessine le bâtiment. L'urbaniste raisonne à l'échelle du quartier et se moque de savoir où passera une gaine.

Le monde informatique a exactement les mêmes trois étages, et la même confusion dans les intitulés de poste.

L'architecte d'infrastructure conçoit le socle : réseaux, serveurs, stockage, plateformes cloud, capacité, continuité de service. Il répond de ce qui porte les applications, pas de ce qu'elles contiennent.

L'architecte logiciel conçoit le système : les composants et ce que chacun fait, la stack technique, le magasin de données, la façon dont les services se parlent. C'est le sujet de cette série.

L'architecte d'entreprise travaille au-dessus des deux : cartographie du système d'information, cohérence du portefeuille applicatif, alignement avec la stratégie de l'organisation. Il décide moins de la forme d'un système que de son droit d'exister.

Les offres d'emploi mélangent allègrement les trois, et y ajoutent « architecte solution », « architecte technique » ou « architecte cloud » selon les modes du moment.

Lis la fiche de poste, jamais l'intitulé. Ce qui change d'un architecte à l'autre, c'est l'échelle du périmètre dont tu réponds quand ça casse.

La responsabilité : ce que le client ne demandera jamais

Le maître d'ouvrage commande une surface, un délai, un budget. Il ne demande jamais que les structures résistent au feu pendant une heure, ni que les circulations laissent passer un fauteuil roulant. Les normes de construction le lui imposent, et c'est l'architecte qui les connaît, les applique et les défend en réunion quand elles coûtent cher.

Le parallèle informatique est direct. Aucun cahier des charges ne contient la ligne « le système doit être rapide, fiable, sûr et maintenable ». Ou plutôt si, il la contient parfois, sans le moindre chiffre derrière, ce qui revient au même.

Ces exigences existent quand même. Elles sont simplement implicites, et personne ne les portera si l'architecte ne le fait pas.

Le piège, c'est de croire que ces propriétés s'ajoutent après coup. On ne rend pas un bâtiment parasismique une fois les fondations coulées. On ne rend pas non plus une application scalable en fin de projet, parce que la décision qui l'en empêche a été prise le premier mois, quand quelqu'un a stocké la session utilisateur dans la mémoire du processus.

Ce que le client ne demande pas fait autant partie du périmètre que ce qu'il demande. La différence, c'est que personne ne te le rappellera.

Chiffrer ces exigences est un métier à part entière : latence, débit, volumétrie, utilisateurs concurrents, SLA. C'est l'objet du billet suivant, Le processus d'architecture. Ici, retiens seulement à qui incombe la charge de les écrire.

Le mindset : comprendre le métier avant la technique

Le maître d'ouvrage ne veut pas des cloisons. Il veut louer quatre mille mètres carrés de bureaux avant septembre, parce que son plan de financement l'exige. Tout le programme du bâtiment découle de cette phrase, y compris des décisions qui n'ont rien à voir avec les cloisons.

Un architecte logiciel qui ne sait pas comment son client gagne de l'argent conçoit à l'aveugle. Celui qui sait que la marge annuelle se fait sur trois jours de soldes ne dimensionne pas comme celui qui l'ignore. Ce n'est pas de la culture générale, c'est une entrée de conception.

De là vient la confusion la plus coûteuse du métier : prendre un objectif pour une exigence.

Un objectif est un résultat que le client veut obtenir : il se discute, il se reformule, et le client en change parfois. Une exigence est une propriété du système qu'on peut vérifier : elle se mesure et elle se recette.

Regarde la colonne du milieu. Aucun de ces trois clients n'a menti, aucun n'a été imprécis de mauvaise foi. Ils ont simplement exprimé un besoin dans le seul vocabulaire dont ils disposaient : celui des solutions qu'ils ont vues ailleurs.

La question qui débloque tout se pose sans agressivité et se répète autant que nécessaire : pour quoi faire ? Tant que la réponse reste technique, tu n'as pas atteint l'objectif. Quand elle devient métier, tu peux commencer à concevoir.

Une fois l'objectif attrapé, l'exigence s'écrit. Toujours par écrit, toujours mesurable, toujours avec sa source :

Objectif métier : ne plus vendre en ligne un article déjà parti en magasin
Exigence        : le stock affiché reflète une vente encaissée en moins de
                  5 secondes, jusqu'à 300 caisses actives simultanément
Mesure          : écart entre horodatage d'encaissement et horodatage
                  d'affichage, 95e centile relevé chaque heure
Source          : entretien du 12 mars, direction des opérations
Si non tenue    : annulation de commande, remboursement, client perdu

Cinq champs. Ils valent mieux qu'une réunion de deux heures, parce qu'ils se relisent en janvier quand tout le monde a oublié qui avait dit quoi.

Un objectif se discute, une exigence se vérifie. Tant que tu n'as pas transformé le premier en la seconde, tu n'as rien à concevoir.

Parler la langue de son interlocuteur

Réunion de chantier du mardi matin. Autour de la table : le maître d'ouvrage qui compte en euros et en mois, le chef de chantier qui compte en équipes et en jours ouvrés, l'entreprise de gros œuvre qui compte en mètres cubes de béton. Le même retard de livraison se raconte de trois façons différentes, et pour chacun une seule fonctionne.

L'architecte logiciel vit la même scène toutes les semaines. Son travail ne vaut que ce qu'il arrive à en faire passer.

La colonne de droite n'est pas de la diplomatie. C'est de la précision adaptée au bon niveau d'abstraction. Dire « CQRS » à une direction générale ne la renseigne sur rien et la met mal à l'aise, ce qui est le plus sûr moyen de faire refuser une bonne décision.

À l'inverse, servir aux développeurs une consigne sans raison produit toujours le même effet différé. Ils appliquent, puis contournent dès que la consigne les gêne. Tu l'apprends six mois plus tard, en relisant le code.

L'autorité obtient de la conformité, l'explication obtient de l'adhésion. Sur un système qui vivra dix ans, seule la seconde tient.

L'influence sans autorité repose sur trois appuis simples : donner les raisons plutôt que les ordres, accepter publiquement une meilleure idée quand elle arrive, et rester présent pendant la réalisation. La réunion de chantier hebdomadaire n'a pas d'équivalent plus efficace : un architecte qui disparaît après la remise du document découvre à la livraison un bâtiment qui ne ressemble pas à ses plans.

L'architecte doit-il coder ?

Le maître d'œuvre ne monte pas sur l'échafaudage tous les jours. Mais celui qui n'a jamais tenu une truelle dessine des détails infaisables, et les compagnons le savent avant lui.

La réponse honnête est oui, avec une restriction nette : pas sur le chemin critique.

Un architecte qui ne code plus du tout perd le contact en deux ans. Pas le contact avec la syntaxe, ça se rattrape. Le contact avec ce que coûte réellement une de ses décisions dans la vraie vie d'une équipe : le temps de compilation, la pénibilité d'un test d'intégration, le nombre de fichiers à toucher pour ajouter un champ. Ces coûts ne se lisent pas dans un schéma.

Un architecte qui code une fonctionnalité livrable pose le problème inverse. Il devient un goulot d'étranglement, et son travail de conception passe systématiquement après l'urgence du sprint. Le document d'architecture attend toujours le sprint suivant.

La ligne de partage est utile parce qu'elle est simple.

Ce qu'il devrait coder : le squelette du projet et les conventions qui vont avec, un prototype qui tranche une question ouverte, une preuve de charge sur la technologie candidate, une brique transverse que personne d'autre ne veut porter.

Ce qu'il ne devrait pas coder : une user story du sprint dont trois personnes dépendent vendredi.

Écris du code qui répond à une question de conception, jamais du code dont le sprint dépend.

Il y a un bénéfice secondaire, et il est loin d'être secondaire. On suit plus volontiers quelqu'un qui a déjà subi les conséquences de ses propres plans.

Comment on arrive au poste

Personne ne devient chef de chantier en changeant de carte de visite. On y arrive par un corps de métier, puis par assez d'années passées à voir des ouvrages finis pour reconnaître un plan qui ne passera pas.

Les parcours vers l'architecture sont peu nombreux et assez stables.

La voie majoritaire passe par le développement : quelques années sur une stack, puis un rôle de tech lead où l'on commence à décider pour d'autres. La voie infrastructure existe aussi, et donne souvent de meilleurs architectes sur tout ce qui touche à l'exploitation, parce que ces gens-là ont déjà été réveillés la nuit.

La marche qui coince est rarement technique. C'est l'écrit. Un bon développeur promu architecte sait presque toujours concevoir ; il découvre qu'il doit désormais convaincre par un document que d'autres liront sans lui dans la pièce. Cette compétence-là se travaille, et elle se travaille en écrivant. Le format de ce livrable a d'ailleurs son propre billet en fin de série, Le document d'architecture.

Côté certifications, le paysage est modeste. Les fournisseurs cloud proposent des parcours orientés vers leurs plateformes. Côté architecture d'entreprise, TOGAF fournit un cadre et surtout un vocabulaire partagé, ce qui n'est pas rien quand on parle à des directions.

Aucune certification ne remplace un système qu'on a conçu, livré, puis exploité assez longtemps pour en voir les défauts.

Scénario B : Hertz contre Accenture

En avril 2019, Hertz Global Holdings dépose plainte contre Accenture LLP devant le tribunal fédéral du district sud de New York. Le loueur de véhicules réclame plus de 32 millions de dollars, le montant qu'il déclare avoir versé pour la refonte de son site web et de ses applications mobiles.

Le déroulé, tel que la plainte le présente : Accenture est retenue en 2016, la mise en ligne est visée pour fin 2017, repoussée une première fois, puis une seconde, et Hertz met fin au contrat au printemps 2018 sans qu'aucune version exploitable ait été livrée.

Deux griefs ressortent du dossier. Le premier porte sur un « cœur commun extensible », une base technique censée servir les différentes marques du groupe, dont Dollar et Thrifty. La plainte la décrit comme jamais livrée en état. Le second grief est plus concret encore : toujours selon la plainte, l'interface livrée ne s'adaptait pas aux tablettes, faute d'avoir été prévue pour ce format d'écran.

Une précaution s'impose avant d'en tirer quoi que ce soit. Ce sont les allégations d'une seule partie, dans une procédure civile. Accenture les a contestées, et l'affaire s'est réglée hors tribunal, sans décision de justice sur le fond. On ne juge personne ici.

Ce que le dossier montre en revanche, indépendamment de qui avait raison, c'est la forme que prend un projet où la cohérence d'ensemble n'est portée par personne.

Un « cœur commun réutilisable entre les marques » est une décision d'architecture déguisée en fonctionnalité. Elle réclame un périmètre écrit, des interfaces définies et un coût chiffré, puis un suivi du premier jour à la recette. Un site « responsive » sans liste explicite des tailles d'écran cibles reste, lui, au stade de l'objectif. Et un objectif ne se recette pas.

Transposé sur Le Chantier : le maître d'ouvrage a confié les plans à l'entreprise de gros œuvre, n'a envoyé personne aux réunions hebdomadaires, et a découvert à la livraison que l'ascenseur ne desservait pas le troisième étage.

Quand personne ne tient la cohérence de l'ensemble, ce n'est pas une ligne de code qui casse. C'est le projet, et la facture arrive deux ans plus tard.

Points clés

• Le développeur sait ce qui peut être fait, l'architecte doit savoir ce qui devrait l'être. Le poste change de nature, pas seulement de niveau.
• Les exigences implicites (rapide, fiable, sûr, maintenable, exploitable) font partie du périmètre même quand personne ne les écrit. Personne ne les écrira à ta place.
• Un objectif métier n'est pas une exigence. Pose la question « pour quoi faire ? » jusqu'à obtenir une réponse métier, puis écris une propriété mesurable.
• L'architecte n'a presque jamais d'autorité hiérarchique sur ceux qu'il doit convaincre : il compense en adaptant son langage et en donnant les raisons de ses décisions.
• Coder oui, mais des prototypes, des squelettes et des preuves de charge. Pas des tâches du sprint dont l'équipe dépend.

Dans la série

Palier 1 : Lire le terrain. Domaine : Business.

• Suivant : Le processus d'architecture : six étapes, des exigences au support
• Vue d'ensemble : Architecture logicielle : par où commencer

Pour aller plus loin

• Le processus d'architecture : six étapes, des exigences au support : comment chiffrer les exigences dont ce billet dit qu'elles t'incombent.
• Le document d'architecture : de l'étude de cas au livrable : le livrable par lequel l'architecte convainc quand il n'est pas dans la pièce.
• TOGAF (The Open Group) : le cadre de référence côté architecture d'entreprise.
• Hertz Global Holdings, Inc. v. Accenture LLP, plainte déposée en avril 2019 devant l'U.S. District Court for the Southern District of New York : documents publics de l'affaire et couverture de presse d'époque.