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.
Combien de temps faut-il pour obtenir un signal fiable ?
Un premier signal apparaît souvent en 2 à 4 semaines si le workflow est bien borné et si une baseline existe pour la métrique temps d'analyse.
Faut-il commencer par un outil ou par un cas d'usage ?
Par le cas d'usage et par la friction à supprimer. L'outil se choisit ensuite selon le contexte, les droits, les intégrations nécessaires et le niveau de risque.
Comment éviter les gains déclaratifs ?
Mesurez au moins un indicateur avant/après, par exemple temps d'analyse, décisions documentées ou incidents liés à architecture, et demandez une preuve opérationnelle.
Quand faut-il arrêter un pilote IA ?
Quand le gain est trop faible, quand le risque résiduel reste trop élevé ou quand l'équipe ne peut pas maintenir le cas sans support disproportionné.
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.