L'architecte n'a pas besoin d'une réponse, mais d'un meilleur champ d'options
Un architecte n'a pas besoin que l'IA choisisse à sa place. Il a besoin d'explorer plus vite les options, de rendre visibles les angles morts, de comparer les compromis et de documenter la décision sans perdre le contexte.
L'IA est intéressante comme sparring partner : elle formule des alternatives, questionne les contraintes, propose des scénarios de charge ou de panne. La responsabilité du choix reste humaine.
"L'IA a préparé les angles morts. L'architecte a gardé la décision."
Une mauvaise exploration coûte cher même quand la décision semble rapide
Une mauvaise exploration coûte cher même quand la décision semble rapide. Si le contexte est incomplet, l'option retenue paraît cohérente sur le papier, puis se fragilise au contact des contraintes de run, de sécurité ou de scalabilité.
Les risques ne sont pas abstraits. Ils apparaissent dans le quotidien des équipes :
- raisonnement plausible mais faux
- contexte incomplet
- choix non assumé
- standardisation abusive
Le coût se paie en ADR faibles, en choix difficiles à expliquer et en standards appliqués trop mécaniquement. Une architecture plausible n'est pas forcément une architecture assumable.
Utiliser l'IA pour comparer, challenger et documenter
La bonne réponse ne consiste pas à demander au modèle de choisir l'architecture cible. Elle consiste à installer un sparring partner architectural qui produit options, risques, ADR et questions de validation. Cette approche garde l'ambition, mais elle impose une discipline simple : chaque usage IA doit produire un livrable, une métrique, un propriétaire et une décision explicite de continuation ou d'arrêt.
1. Capturer contraintes et objectifs
La capture des contraintes doit précéder toute génération d'options : objectifs métier, contraintes réglementaires, dette existante, limites d'équipe, exigences de run, coûts de migration, réversibilité attendue.
- Décision attendue : choisir le périmètre pilote et ce qui restera hors champ.
- Preuve attendue : une mesure avant déploiement, même imparfaite.
- Anti-pattern : lancer un assistant généraliste sans workflow prioritaire.
2. Générer options comparables
Les options doivent être comparables. Même format, mêmes critères, mêmes hypothèses, mêmes inconnues. L'IA peut préparer cette matrice de trade-offs et proposer les questions qui manquent.
La matrice n'est pas la décision. Elle rend la décision plus explicite, donc plus facile à challenger.
3. Tester scénarios de charge et panne
Les scénarios qualité donnent de la matière : charge, panne, montée en version, rollback, sécurité, observabilité, coût d'exploitation. Ils obligent chaque option à sortir du discours général.
Le livrable doit inclure ce qui ferait changer la décision. Sans critères de réversibilité, l'ADR devient une justification après coup.
4. Rédiger ADR et critères de réversibilité
Le pilote doit démontrer que l'architecte décide mieux, pas seulement plus vite. On mesure le temps d'analyse, les décisions documentées, les incidents liés à l'architecture et la réversibilité des choix. Le livrable de pilotage : questions de revue.
| Étape | Livrable | Signal de qualité |
|---|---|---|
| Cadrage | ADR | Baseline temps d'analyse disponible |
| Responsabilité | matrice de trade-offs | Validateur humain nommé |
| Contexte | scénarios qualité | Sources et droits explicités |
| Pilotage | questions de revue | Décision go/stop à date fixe |
:::
Quand la décision devient plus claire sans devenir plus légère
La décision devient plus claire quand les options refusées sont aussi documentées. L'équipe comprend mieux le choix, ses limites et les signaux qui devront déclencher une révision.
Le bon usage de l'IA raccourcit la préparation, pas la responsabilité. L'architecte gagne du temps sur l'exploration et le formalisme, puis investit ce temps dans le jugement.
Un pilote de réflexion architecturale sur une vraie bifurcation
Le pilote doit porter sur une vraie bifurcation : choix d'intégration, découpage de module, stratégie de migration, résilience d'une brique critique. Un faux sujet produira une fausse preuve.
Pour ce thème, le pilote doit contenir cinq éléments :
- un sponsor capable d'arbitrer les priorités ;
- un propriétaire opérationnel du workflow ;
- un jeu de données ou de cas réels relié à scénarios qualité ;
- une règle claire sur les usages interdits ;
- une date de revue avec décision de continuation ou d'arrêt.
L'objectif est d'améliorer la préparation du comité architecture, pas de produire une architecture automatique.
Les signaux qui montrent qu'une aide reste un appui et non un substitut
Une aide reste un appui si elle rend les hypothèses plus visibles, pas si elle donne une réponse plus séduisante. Les signaux à suivre sont le temps d'analyse, la qualité des ADR, les décisions documentées et les incidents liés à des angles morts architecturaux.
Si les architectes passent leur temps à corriger des raisonnements faux, le périmètre doit être réduit à la préparation documentaire ou aux questions de revue.
Quel rôle l'IA doit-elle jouer auprès d'un architecte logiciel ?
Elle agit comme sparring partner : elle explore des options, expose des angles morts, prépare des scénarios et structure la documentation. Le choix et sa responsabilité restent ceux de l'architecte.
Comment rendre plusieurs options d'architecture comparables ?
Présentez-les avec les mêmes critères, hypothèses, contraintes et inconnues. La matrice de trade-offs doit couvrir aussi le run, la sécurité, la scalabilité, les coûts de migration et la réversibilité.
Que doit préciser un ADR préparé avec l'IA ?
Il documente l'option retenue, les options écartées, les hypothèses, les scénarios qualité et les signaux qui feraient réviser la décision. L'agent ne doit pas inventer une justification absente.
Quand faut-il réduire le périmètre de l'aide architecturale ?
Si les architectes corrigent surtout des raisonnements plausibles mais faux, limitez l'agent à la préparation documentaire ou aux questions de revue. Le temps d'analyse ne doit pas baisser au prix de choix moins réversibles.
Le temps d'analyse baisse seulement si la qualité du choix tient
Le temps d'analyse baisse seulement si la qualité du choix tient. Une décision plus rapide mais moins réversible ou moins documentée n'est pas un gain d'architecture.