La revue d'architecture reste humaine

Le fil de cette série tient en une phrase : le métier de développeur glisse de produire vers décider. Et parmi toutes les décisions, l'architecture est celle qui a le plus de levier — celle qui engage le système, et l'équipe qui le porte, pour des années. Or l'IA sait désormais y toucher : elle suggère un pattern, un choix de bibliothèque, du scaffolding, et va jusqu'à rédiger une ébauche de conception plausible et bien argumentée. La tentation est réelle de la laisser trancher. Mais concevoir une architecture, c'est arbitrer des compromis contre vos contraintes — celles que l'IA ne connaît pas. Elle est une source d'options et un partenaire de réflexion ; la décision de structure, elle, reste un jugement humain, et il est imputable.

L'IA sait ébaucher une conception — et c'est utile

Commençons par le gain, car il est authentique. Explorer l'espace des conceptions possibles est un travail lent : lister les options, se rappeler les patterns, peser leurs compromis connus. C'est exactement là que l'assistant rend service. Demandez-lui trois façons de découper un service, les implications d'un modèle événementiel, les bibliothèques candidates pour un besoin donné : il vous rend en quelques minutes un tour d'horizon qui prendrait des heures de lecture. Il produit une première ébauche de structure, un squelette de projet, un diagramme de départ. Et surtout, il tient le rôle d'un interlocuteur infatigable : on lui expose une idée, il en montre les angles morts, il propose une alternative. Ce partenariat a une valeur réelle, et s'en priver serait absurde (Fig. 2, à gauche).

Ce gain a la même nature que celui décrit ailleurs dans la série : générer des propositions est devenu bon marché ; décider laquelle tient reste le travail. L'IA excelle à produire des options ; elle est faible à choisir la bonne pour vous. Elle connaît les compromis génériques d'un choix d'architecture — ce qu'un manuel en dirait — mais pas leur poids dans votre situation. Cette dissymétrie n'est pas un défaut passager de l'outil : elle vient de ce que l'architecture n'est pas une question de forme, mais d'adéquation à un contexte que l'outil ne détient pas. C'est là que la revue de conception cesse d'être délégable.

Pourquoi les décisions de structure ne se délèguent pas

Toutes les décisions d'un projet n'ont pas le même poids, et l'architecture désigne précisément les plus lourdes. Ralph Johnson en donne la définition la plus citée, reprise par Martin Fowler dans son guide de l'architecture logicielle : « l'architecture, c'est ce qui compte vraiment — quoi que ce soit ». Fowler la reformule d'une manière qui éclaire notre sujet : ce sont « les décisions qu'on aimerait prendre correctement dès le début d'un projet » — celles qui, une fois prises, sont perçues comme difficiles à changer. Renommer une variable ne coûte rien ; déplacer une frontière entre deux services, changer de modèle de données, revenir sur un choix construire-ou-acheter, cela se paie longtemps (Fig. 1).

Cette différence de coût a un nom parlant, emprunté au monde de la décision. Dans sa lettre aux actionnaires de 2015, le dirigeant d'Amazon distingue deux types de décisions. Les unes sont « conséquentes et irréversibles, ou quasi irréversibles — des portes à sens unique — et doivent être prises méthodiquement, avec soin, lentement, après mûre délibération » ; les autres « sont modifiables, réversibles — des portes à double sens ». La plupart des décisions de code sont des portes à double sens : on rouvre, on revient en arrière, le coût de retour est faible. Beaucoup de décisions d'architecture sont des portes à sens unique : une fois l'équipe et le système engagés, revenir coûte des mois. Voilà pourquoi elles ne se tranchent pas sur la foi d'une génération plausible — la même prudence, appliquée un cran plus haut, que celle qui commande de spécifier avant de générer.

Ce que l'IA ne peut pas savoir de votre contexte

Ici se tient la limite de fond. Une part décisive de ce qui fait qu'une architecture est bonne pour vous n'est nulle part dans le texte que l'IA peut lire. Les contraintes de l'organisation — budget, échéances, dépendances imposées, contrats. La roadmap — ce qui arrive dans six mois et qui rendra ce découpage bienvenu ou intenable. Les compétences réelles de l'équipe — une architecture élégante que personne ne saura exploiter est une mauvaise architecture. L'histoire du système — pourquoi tel module existe, quelle migration a été laissée à moitié, quelles cicatrices interdisent certains choix. Et le coût de possession à long terme — ce que cette structure coûtera à faire vivre, pas seulement à construire. Rien de tout cela n'est dans un dépôt de code ; l'IA propose donc pour un projet moyen, jamais pour le vôtre (Fig. 2).

On objectera qu'il suffit de « donner le contexte » à l'outil. C'est en partie vrai, et c'est un vrai levier — mais avec deux limites nettes. D'abord, une grande part de ce contexte est tacite : il vit dans les têtes, les couloirs, les arbitrages passés, et ne se met pas en prompt. Ensuite, même lorsqu'on fournit beaucoup de matière, les modèles l'exploitent mal. L'étude Lost in the Middle: How Language Models Use Long Contexts (Liu, Lin, Hewitt et coll., arXiv 2307.03172) le montre : « la performance est souvent la meilleure quand l'information utile est au début ou à la fin du contexte, et se dégrade nettement quand le modèle doit aller la chercher au milieu de longs contextes ». Bien cadrer ce qu'on transmet — le contexte donné à l'outil — améliore la carte ; cela ne remplace pas la connaissance vécue de votre système.

À cette limite s'ajoute la propriété la plus traître pour une revue de conception : la fluidité trompeuse. Une ébauche d'architecture générée arrive claire, structurée, sûre d'elle — et cette assurance ne prouve rien. La grande synthèse A Survey on Hallucination in Large Language Models (Huang, Yu, Ma et coll., arXiv 2311.05232, à paraître dans ACM Transactions on Information Systems) le rappelle : les modèles tendent à produire « un contenu plausible mais non factuel ». Transposé à la conception, cela donne un plan qui se tient sur le papier mais ignore une contrainte que vous êtes seul à connaître, ou invente une justification vraisemblable. Le danger n'est pas que l'IA se trompe ; c'est qu'elle se trompe avec éloquence, et qu'une belle argumentation emporte l'adhésion à la place d'un examen des compromis.

La décision d'architecture reste un jugement humain

Reste à nommer ce qui rend ce nœud non délégable au-delà de la technique : la responsabilité. Une architecture engage des personnes — l'équipe qui la maintiendra, les utilisateurs qui en subiront les défauts — et cet engagement demande un répondant. L'IA ne répond de rien : elle ne connaît ni les conséquences de son plan, ni le contexte qui les détermine, et n'assume aucune suite. Adopter une conception parce qu'elle a été générée ne dilue pas la responsabilité de ce qui est livré ; elle reste attachée à qui appose son nom sur la décision. C'est le même déplacement que dans tout le reste de la série : le rôle n'est plus de produire, mais de réviser et de trancher — et il n'y a pas de niveau où ce rôle compte davantage que celui de la structure.

Ce répondant humain a un adversaire bien documenté : le réflexe d'approuver ce qui est fluide. Le profil « IA générative » du NIST (AI 600-1) le nomme sans détour : « les humains peuvent trop se fier aux systèmes d'IA générative… c'est un exemple de biais d'automatisation, ou de déférence excessive envers les systèmes automatisés ». Sur une revue de conception, ce biais est maximal, car une ébauche bien tournée ressemble à une décision mûrie. La discipline consiste donc à traiter toute proposition de l'IA comme une hypothèse à éprouver contre vos contraintes — jamais comme un arbitrage rendu. L'outil est excellent pour explorer ; il n'est pas là pour décider. Choisir entre construire et acheter, par exemple, mobilise autant votre roadmap et vos coûts internes que les mérites techniques comparés — un arbitrage voisin de celui qu'on mène pour comparer des logiciels concurrents avec l'IA, où l'outil dresse le tableau mais où la décision vous revient.

La revue d'architecture reste donc humaine, non par méfiance envers l'outil, mais par nature de la décision. L'IA vous fait gagner l'exploration — les options, l'ébauche, le contradicteur — et il faut s'en saisir pleinement. Mais l'arbitrage, lui, engage un système et une équipe pour des années, contre des contraintes qu'elle ne connaît pas, sous une responsabilité qu'elle ne porte pas. Se servir de l'IA en conception, ce n'est pas lui demander la réponse ; c'est lui demander les questions, puis trancher soi-même — et assumer la porte que l'on franchit.