Décider, c’est oser. Ne rien faire, c’est subir.
1. Prendre une décision d’architecture, ce n’est pas si simple… sauf quand on ne la prend pas.
Ce matin, réunion avec l’équipe projet sur l’avancement des tâches. Une question survient sur un sujet, iles performances ne sont pas bonnes. Mais alors : quelles ressources CPU et mémoire demander pour un déploiement sur Rancher ?
L’équipe a bossé il y a quelques semaines, elle a proposé une estimation à 40 Go de mémoire. Pourtant, le dossier d’architecture ne mentionne rien. Le déploiement est là et les ressources sont limitées à environ 1,5 Go en réservé et 2,5 Go en limite. L’application rame beaucoup. Oui, tout n’est pas encore au point, certaines interfaces ne fonctionnent pas, mais bon. Réponse de l’architecte : « Il faut réparer les interfaces et puis tester pour affiner les ressources. »
…
1500 quoi ? 1500 versus 40 000 ? Pourquoi ? Personne ne sait. Et surtout : sur quelle base ? Mystère. Aucune analyse, aucun calcul. Juste une envie de « voir ce que ça donne ». Le tout sans engager la moindre discussion sur le sujet.
Et ce n’est pas un cas isolé. J’observe de plus en plus d’architectes qui refusent de trancher. Alors que c’est justement ça, le cœur du métier.
Pourquoi ? Qu’est-ce qui bloque ? Pourquoi est-ce si dur de décider ?
2. Les raisons pour lesquelles c’est (vraiment) difficile
a. Il y a rarement une seule bonne réponse
Chaque décision d’architecture est un compromis. Et on adore les compromis. C’est comme choisir entre une pizza 4 fromages et une raclette : les deux sont bons, mais ça n’a pas les mêmes conséquences (surtout pour le cholestérol et les réunions post-déjeuner).
Les contraintes sont multiples : performance, coûts, disponibilités, compétences, maintenabilité… Alors oui, c’est difficile de choisir. Mais c’est justement parce qu’il n’y a pas de solution parfaite qu’on a besoin de quelqu’un qui fait des études, qui pèse le pour et le contre de chaque solution, qui partage tout cela et qui tranche — ou qui fait en sorte que le boss tranche.
b. Le manque d’informations précises
Souvent, on nous demande de décider sans spécifications fonctionnelles, sans estimations de charge, sans historique de consommation. L’équivalent de : « Choisis un moteur pour la voiture, mais on ne sait pas si c’est pour de la Formule 1 ou pour faire le marché du dimanche. »
Mais dans ce cas, faire une hypothèse, proposer un cadre, expliquer les limites, c’est trente-six mille fois plus utile que de dire : « Essayons et voyons ensuite. » Il faut arrêter de faire des maquettes et de les faire partir en prod comme si c’était une version stable et industrialisée.
c. La peur de s’engager
L’autre problème, c’est la responsabilité. Beaucoup d’architectes ont peur de se planter. Peur d’être accusés d’avoir mal anticipé. Du coup, ils se protègent : pas de décision = pas de risque.
Sauf que l’inaction est un choix. Et souvent, c’est le pire.
Il y a pourtant une solution à cela : le tableau des décisions d’architecture. On note le point, on explique pourquoi cette décision est prise, avec qui elle est partagée. On peut toujours être critiqué, mais au moins, on documente les raisons du choix, avec les informations connues à l’instant T. Et surtout, on évite le syndrome du « je sais pas qui a validé ça, mais c’est pas moi ».
d. La tentation du blabla stratégique
Certains architectes s’en sortent par le verbe : TOGAF, ArchiMate, cartographies détaillées… tout pour éviter de dire : « mets 2 CPU et 8 Go de RAM pour commencer ». On adore les frameworks, les schémas multicolores et les post-its alignés. Mais ça ne répond pas à la question posée : combien on met dans le conteneur pour que ça tienne debout sans brûler le budget ?
e. Et le budget, alors ?
Ah oui, parlons argent. Parce que 1500 Mo de mémoire par pod multiplié par 12 environnements, ça finit par piquer sur la facture cloud. Et pas une petite piqûre de moustique. Non. Une bonne grosse piqûre de guêpe facturée à la minute.
Refuser de chiffrer, c’est ignorer les enjeux financiers. Et quand les développeurs n’ont plus le droit de lancer un pod car on a tout grillé en pré-prod, ça finit toujours sur le dos de quelqu’un… mais rarement celui qui n’a pas décidé. On se retrouve avec des user stories pour améliorer les performances ou l’utilisation de la mémoire — ce qui est utile (et trop peu fait) — mais ces US n’apparaissent pas au bon moment, ni pour les bonnes raisons. C’est l’architecture par rattrapage, et ça coûte cher.
3. Ce que ça donne concrètement dans un projet
Retour à notre cher Rancher. Estimation de l’équipe : 40 Go. Répartition donnée : 1500 / 2500 (unités inconnues, sans justification).
Résultat : confusion, test-and-pray, puis arbitrages en urgence quand ça déborde.
On est passé d’une discussion technique à un numéro de loto. Dommage, parce qu’une décision justifiée aurait évité tout cela.
4. Ce qu’on attend d’un architecte (normalement)
Un architecte, c’est pas juste un type qui fait de beaux schémas et qui parle dans les réunions. C’est quelqu’un qui fait avancer les choses.
On attend de lui qu’il pose des hypothèses claires, qu’il les partage avec l’équipe, et qu’il soit capable d’expliquer les choix faits. Même si ces choix sont temporaires, même si ça repose sur des incertitudes.
On attend aussi qu’il prenne ses responsabilités. Se mouiller, ça fait partie du job. Et non, ça ne veut pas dire se jeter dans la piscine sans savoir nager, mais au moins s’approcher du bord.
Un bon architecte ne reste pas en retrait en espérant que la décision se prenne toute seule. Il accompagne les équipes, il éclaire les zones floues, il fait le lien entre contraintes techniques et enjeux métiers. Et surtout, il ne se planque pas derrière un PowerPoint.
5. Les 3 réflexes de survie de l’architecte qui décide
- Toujours poser une hypothèse, même bancale, plutôt que de rester muet.
Un « Je pense qu’on peut commencer avec ça, et ajuster ensuite » vaut mieux qu’un « On verra bien ». C’est ça, être proactif. - Documenter la décision, même si elle est temporaire.
Un tableau simple, une ligne dans un PAD, un post-it virtuel… Ce n’est pas du formalisme, c’est de la traçabilité. Et surtout, ça protège. - Expliquer les raisons, pas les buzzwords.
« On part sur 2 CPU parce que l’appli est en Java et qu’elle spawne 27 threads à la minute » > « C’est aligné avec le target operating model de la trajectoire Cloud native DevSecFinOps ».
6. Conclusion : L’inaction est pire que la mauvaise décision
Un architecte n’est pas là pour distribuer des slides. Il est là pour aider à construire. Parfois, avec peu d’infos. Parfois, dans le flou. Mais toujours avec une forme d’engagement.
Ce n’est pas grave de se tromper. C’est grave de ne rien proposer.
Et si on veut éviter que tout le monde rame dans le brouillard, il faut que quelqu’un prenne la barre.
Alors les architectes, prenez la barre, affirmez votre vision. Parce que « on verra bien », ce n’est pas une stratégie, c’est une abdication.
