Spec-Driven Development avec Kiro : qui décide ?

Vos agents prennent des décisions d'architecture. Quelqu'un les consigne-t-il ?

À retenir

Le problème des outils de coding IA n'est pas de produire du code. C'est que, six mois plus tard, personne ne sait pourquoi le code a cette tête-là. Kiro est la tentative la plus directe pour y remédier.
Le spec-driven development a un coût. La question n'est pas de savoir s'il ralentit le rythme : oui, c'est le cas. La question est de savoir si votre équipe peut se permettre l'alternative.
Les modes d'échec sont réels : specs superficielles, fausse précision induite par la notation EARS, ADR qui paraissent complets sans l'être. Le workflow ne fonctionne que si les points de validation en sont vraiment.

Les outils de coding IA sont devenus bons pour produire du code. Vraiment bons. Frameworks multi-agents, assistants agentiques, pipelines autonomes : si l'enjeu est de transformer une idée en code fonctionnel, l'offre est à la hauteur. Mais quand on développe en équipe, on a sans doute heurté le mur qui se dresse environ deux semaines après la démo impressionnante : le code tourne, personne ne sait pourquoi il a cette tête-là, et quand quelqu'un demande pourquoi telle approche a été retenue, la réponse honnête tient en une phrase : j'ai laissé l'agent décider, et je ne sais pas vraiment.

J'ai vu ce scénario se rejouer dans plusieurs équipes. Le problème n'est pas que l'agent ait fait de mauvais choix. C'est que la quasi-totalité des outils de coding IA du marché optimisent pour l'exécution de tâches, et que rares sont ceux qui investissent dans les artefacts qui maintiennent la cohérence d'un développement en équipe sur la durée.

Kiro d'Amazon, lancé en preview en juillet 2025, est la tentative la plus directe que j'aie vue pour combler ce vide. Il ne s'agit pas d'opposer Kiro à Cursor ; pour la vitesse brute sur des tâches isolées, Cursor, Claude Code et les frameworks multi-agents sont redoutables. La vraie question est de savoir si le modèle de spec-driven development de Kiro, couplé à un workflow d'Architecture Decision Record (ADR) configurable via son système Steering, apporte aux équipes ce que ces outils ne fournissent pas : une trace partagée et révisable par des humains de la manière dont le logiciel a été conçu, et pourquoi.

Le paysage multi-agents : puissant, mais structurellement incomplet

La génération actuelle de frameworks multi-agents (CrewAI, LangGraph, AutoGen, MetaGPT) est mature. Des entreprises comme DocuSign et PwC font tourner des pipelines multi-agents en production à grande échelle. L'argument en faveur de Kiro ne tient que si l'on accepte que l'alternative sait déjà produire du code.

MetaGPT mérite un examen direct — moins répandu en production que LangGraph ou CrewAI, c'est néanmoins celui qui recoupe le plus ce que Kiro prétend offrir. Donnez-lui une exigence en une ligne et il produit des artefacts structurés : PRD, documents de design, spécifications d'interface, code d'implémentation. Sur le papier, cela couvre le même terrain que le workflow spec-driven de Kiro.

La différence structurelle ne porte pas sur la qualité de la sortie, mais sur qui voit les décisions, et à quel moment.

Dans MetaGPT, les agents produisent des artefacts et passent la main à l'agent suivant. La sortie est complète, mais le processus reste opaque : les décisions prises par l'agent Architect ne sont pas exposées comme des éléments révisables. Aucun point de validation où votre équipe lit le document de design et signale une contrainte avant le démarrage de l'implémentation. Les artefacts sont des sorties à consommer, pas des documents collaboratifs à réviser.

Le même écart se retrouve dans les frameworks multi-agents en général. Ce sont d'excellents moteurs d'exécution. Ils n'ont pas été conçus pour produire une compréhension partagée, à l'échelle de l'équipe, des raisons pour lesquelles le logiciel a été construit d'une certaine façon. C'est un parti pris de design, pas un défaut. Ces frameworks optimisent pour l'achèvement des tâches. Kiro optimise pour la lisibilité de l'équipe dans le temps.

Ce que fait réellement Kiro

Kiro est un fork de VS Code propulsé par Claude Sonnet sur Amazon Bedrock. L'environnement familier compte : aucun nouvel IDE à apprendre, aucun changement de contexte, et les plugins Open VSX existants, les thèmes et les paramètres se migrent sans accroc. Comme c'est un IDE généraliste, Kiro fonctionne avec tous les langages et frameworks, même si le workflow spec-driven se prête le plus naturellement au backend et au full-stack, là où les décisions d'architecture pèsent le plus lourd.

La différenciation tient au workflow qu'il impose.

Spec-driven development : les artefacts avant l'exécution

Chaque feature dans Kiro commence par une spec, un ensemble de fichiers Markdown structurés commités dans le dépôt avant qu'une seule ligne de code ne soit écrite. Le processus en trois phases est délibéré :

Phase 1 : exigences (requirements.md)

Le premier point de validation est celui que la plupart des équipes sautent purement et simplement : des exigences écrites, relues et approuvées avant qu'un seul bout de code n'existe. Vous décrivez ce que vous voulez en langage naturel. Kiro ne se met pas à coder. Il produit à la place un document d'exigences formel via la notation EARS (Easy Approach to Requirements Syntax), un format qui contraint chaque exigence à une forme non ambiguë et testable :

WHEN [trigger condition] THE SYSTEM SHALL [observable behavior]

La notation EARS fait remonter des hypothèses qui resteraient autrement implicites. Si Kiro génère un critère d'acceptation que vous n'aviez pas prévu, vous le repérez ici, pas en code review, ni en production. Les exigences sont relues et approuvées par un humain avant que quoi que ce soit d'autre ne se passe.

Phase 2 : design technique (design.md)

C'est la phase où devraient se tenir les vrais débats d'architecture — et celle où la plupart des outils IA ont déjà commencé à pondre du code. Une fois les exigences approuvées, Kiro analyse la base de code existante et génère un document de design : hiérarchies de composants, diagrammes de flux de données, schémas de base de données, contrats d'API, interfaces TypeScript. Le design reflète l'architecture réelle de votre projet.

C'est le document que votre équipe relit avant qu'une seule ligne de code de production ne soit écrite. Un architecte peut contester un schéma. Un senior peut signaler un enjeu de scalabilité. Un ingénieur travaillant sur une feature parallèle peut vérifier si le nouveau design crée des conflits d'intégration avec son travail. Le tout sur un artefact écrit, dans une pull request.

Phase 3 : tâches d'implémentation (tasks.md)

C'est seulement à ce stade que l'implémentation commence. Kiro génère une liste de tâches ordonnées par dépendances et rattachées aux exigences ; chaque tâche inclut les tests unitaires et d'intégration pertinents et, le cas échéant, les états de chargement et les considérations d'accessibilité. Les tâches peuvent s'exécuter une à une avec validation humaine explicite à chaque étape, ou de manière autonome en mode autopilot. Les diffs de code et l'historique d'exécution de l'agent restent visibles à chaque étape.

Les fichiers de spec vivent dans .kiro/specs/<feature-name>/ à l'intérieur du dépôt du projet. Ils sont commités, versionnés, révisables dans les pull requests, et navigables via l'historique git. Toute l'équipe les voit dès qu'ils existent.

Cette visibilité change la façon dont les ingénieurs seniors emploient leur temps. Au lieu de se faire happer par l'archéologie consistant à reconstituer ce qui a été décidé et pourquoi, ils relisent un design écrit, contestent ce qui doit l'être et approuvent avant le démarrage des travaux. Leur jugement s'applique là où il a le plus d'effet de levier.

Ce que les outils multi-agents ne comblent pas : le decision record

C'est là que la comparaison avec les frameworks multi-agents devient tranchante, et où le choix d'outil entraîne des conséquences à long terme qu'une démo courte ne révèle pas.

Les fichiers de spec de Kiro documentent ce que le système doit faire et comment il a été conçu pour le faire. C'est déjà davantage que ce que conservent la plupart des workflows assistés par IA. Mais design.md vous indiquera que PostgreSQL a été retenu et décrira le schéma. Il ne vous dira pas que DynamoDB a été évalué puis écarté parce que vos patterns d'accès exigent un filtrage multi-colonnes que le modèle de requête de DynamoDB ne sait pas gérer sans dénormalisation coûteuse et chemins d'écriture dupliqués. Il ne vous dira pas que l'event sourcing a été envisagé puis écarté parce que l'équipe n'a aucune expérience opérationnelle des event stores et que le budget de latence ne tolère pas la consistance éventuelle.

Ce contexte — ce qui a été évalué, pourquoi cela a été rejeté, quels compromis ont été acceptés — c'est précisément ce que capture un Architecture Decision Record (ADR). Le concept a été introduit par Michael Nygard en 2011 et est devenu depuis un pilier de l'architecture logicielle durable. L'organisation GitHub ADR maintient un bon panorama du format et de ses variantes pour qui veut creuser.

Les ADR sont une pratique bien établie. Le GOV.UK Digital Service en a publié 39 lors de leur migration AWS, couvrant des décisions allant du choix de la plateforme d'hébergement à la consolidation des bases de données et à l'architecture DNS. Chacun est un court fichier Markdown : Status, Context, Decision, Consequences. L'ensemble constitue le journal de décisions de toute la migration, versionné aux côtés de l'infrastructure qu'il décrit.

Si la plupart des équipes ne maintiennent pas d'ADR, c'est par friction. Les produire entre en concurrence avec la pression de livrer, la discipline s'érode au bout d'un sprint ou deux, et les seules décisions réellement consignées sont celles prises en amont, au moment du design — pas les décisions tout aussi importantes qui surgissent en cours d'implémentation, lorsqu'une contrainte se révèle différente de ce qu'on imaginait.

Kiro lève cette friction par deux mécanismes :

Génération automatisée d'ADR via Steering

Le système Steering de Kiro permet de commiter des instructions persistantes dans .kiro/steering/, qui s'appliquent à chaque interaction d'agent au sein de l'équipe. Un seul fichier de steering rend la génération d'ADR automatique :

When generating or updating design.md for any spec, also create or update
a decisions/ subdirectory within the spec folder. For each significant
architectural choice — technology selection, data model, integration
pattern, security mechanism — create an ADR file following the naming
convention ADR-NNN-short-title.md.

Each ADR must include: Status, Context, Decision, and Consequences
(positive, negative, risks). Record options considered but not chosen
and the reasons they were rejected.

Une fois commitée, cette instruction s'applique à toute l'équipe. Les ADR sont produits sans que personne n'ait à y penser.

# ADR-001: Use PostgreSQL over DynamoDB for review storage

## Status
Accepted

## Context
The review system requires complex multi-column filtering (rating, date, product).
DynamoDB's query model requires denormalized duplicates per access pattern,
increasing storage and write complexity by an estimated 3-4x.
The team has existing PostgreSQL operational experience and monitoring tooling.
DynamoDB was the initial default assumption given existing AWS infrastructure.

## Decision
Use PostgreSQL with a normalized schema. Index the columns used in the four
most common filter combinations. Accept the horizontal scaling trade-off.

## Consequences
- Positive: Query logic is significantly simpler; existing tooling applies
- Negative: Horizontal scaling requires more coordination than DynamoDB
- Risk: Revisit if read throughput exceeds 20k RPS at peak; document threshold

Capture des décisions de mi-implémentation via Hooks

Les décisions prises au moment du design sont les plus faciles à capturer. Les dangereuses surviennent pendant l'implémentation : une bibliothèque qui se révèle avoir un cas limite bloquant, une mesure de performance qui change le pattern d'accès aux données. Elles se règlent dans une conversation ou un correctif rapide, et ne sont consignées nulle part.

Un Hook Kiro sur les modifications de design.md règle la question. Quand le document de design est modifié (par un ingénieur ou par Kiro pendant l'exécution d'une tâche), le Hook déclenche un agent qui évalue si le changement constitue une nouvelle décision d'architecture et, le cas échéant, rédige un ADR à relire par l'équipe. La spec et le decision record restent synchronisés tout au long de l'implémentation, pas seulement au moment du design initial.

Les ADR dans les pipelines multi-agents : une approche complémentaire

Les ADR automatisés ne sont pas réservés à Kiro ; on peut ajouter un agent ADR Writer à un pipeline CrewAI ou LangGraph existant. Mais que l'ADR résultant atteigne ou non l'équipe sous une forme révisable dépend de la façon dont vous avez câblé la sortie du pipeline dans votre workflow de développement. Kiro intègre l'ADR dans un workflow où l'équipe le voit, le relit et le conteste avant que le code ne soit écrit.

Pour les équipes qui font déjà tourner des pipelines multi-agents, les deux coexistent naturellement : Kiro gère le design, les specs et la capture des décisions ; votre pipeline existant prend en charge des tâches d'exécution bornées dans le cadre établi par la spec. La spec devient le contrat entre la phase de design (où l'équipe a un droit de regard) et la phase d'exécution (où les agents opèrent avec plus d'autonomie).

Là où le modèle se grippe

Je serais malhonnête de ne pas nommer les modes d'échec, parce qu'ils ne sautent pas aux yeux avant plusieurs sprints.

La qualité de la spec est plafonnée par celle du prompt

Les documents d'exigences et de design produits par Kiro ne valent que ce que vaut la description initiale qu'on lui donne. Un prompt vague produit une spec vague, mais désormais c'est une spec vague avec les apparences de la rigueur, parce qu'elle est mise en forme en notation EARS, avec critères d'acceptation et tout l'attirail. C'est pire que pas de spec du tout, parce que l'équipe la relit, voit la structure et présume que le contenu tient la route.

La parade est culturelle, pas technique : traitez la revue de spec comme une vraie revue de design, pas comme un tampon de validation. Si les exigences semblent génériques ou si le design n'aborde pas vos contraintes spécifiques, contestez avant d'approuver. Tout l'intérêt du point de validation, c'est qu'il en soit un, pas une formalité.

La notation EARS peut produire une fausse précision

EARS est efficace pour lever l'ambiguïté sur des exigences individuelles. Ce qu'elle ne garantit pas, c'est l'exhaustivité : on peut avoir vingt exigences parfaitement non ambiguës qui, collectivement, passent à côté du vrai problème difficile. J'ai vu Kiro générer des exigences EARS techniquement correctes mais opérationnellement inutiles, parce qu'elles décrivent le chemin nominal en détail et ignorent les modes d'échec qui détermineront en réalité si le système tient en production.

La parade : en relisant requirements.md, ne vérifiez pas seulement si chaque exigence est bien formée. Vérifiez si l'ensemble des exigences couvre les cas d'échec, les cas limites et les préoccupations opérationnelles (monitoring, alerting, rollback) qui comptent pour votre système. À défaut, ajoutez-les avant d'approuver.

Les ADR auto-générés peuvent être superficiels

Un fichier de steering qui dit générer des ADR pour les choix d'architecture significatifs produira des ADR. Que ces ADR contiennent un raisonnement utile dépend du contexte dont Kiro dispose sur vos contraintes. Un ADR qui affirme nous avons choisi PostgreSQL parce qu'il supporte les requêtes relationnelles est techniquement correct et parfaitement inutile ; tout ingénieur senior le sait déjà. La valeur réside dans les alternatives écartées et les raisons précises de leur rejet.

Affinez votre fichier de steering pour qu'il soit explicite sur ce que vous voulez voir capturé. Plutôt que consigner les choix significatifs, essayez pour chaque sélection technologique, documenter au moins deux alternatives évaluées, la raison technique ou opérationnelle précise pour laquelle chacune a été rejetée, et les conditions dans lesquelles la décision devrait être réexaminée. Plus l'instruction est précise, plus la sortie est utile.

La dérive de spec est silencieuse par défaut

Kiro ne détecte pas automatiquement quand l'implémentation s'écarte du design. La spec est un instantané d'intention au moment du design. Si un ingénieur (ou un agent en mode autopilot) effectue un changement qui contredit le design (un autre moteur de base de données, un endpoint d'API supplémentaire, un modèle de données modifié), les fichiers de spec ne se mettent pas à jour tout seuls.

C'est solvable avec des Hooks, comme décrit plus haut, mais ce n'est pas le comportement par défaut. Si vous adoptez Kiro, mettre en place des Hooks de détection de dérive doit faire partie de votre configuration initiale, et non d'un ajout après avoir découvert le problème.

La gouvernance s'arrête à la frontière du design

En décembre 2025, un agent Kiro a supprimé un environnement de production AWS en service, provoquant une panne de 13 heures d'AWS Cost Explorer dans une région chinoise (The Register, février 2026). Amazon a attribué l'incident au fait que le rôle de l'ingénieur disposait de permissions plus larges que prévu. Des comptes-rendus indépendants ont décrit Kiro décidant de manière autonome de supprimer puis recréer l'environnement plutôt que d'appliquer un correctif ciblé — une distinction qu'Amazon a contestée.

Les deux récits mènent à la même leçon : une équipe peut avoir des specs relues, des designs approuvés et des ADR documentés, et subir malgré tout une défaillance catastrophique parce que personne n'a relu ce qui s'est passé entre le design approuvé et le déploiement en production.

Le modèle de gouvernance de Kiro couvre la phase de design en profondeur. Ce qu'il ne couvre pas, c'est la frontière d'exécution : l'instant où un agent agit sur de l'infrastructure réelle avec des permissions réelles. Le mode autopilot est utile, mais il exige la même discipline que tout pipeline CI/CD : revue de déploiement, permissions cadrées et un humain dans la boucle avant que les changements n'atteignent la production. Le workflow de spec rend tentant de présumer que la gouvernance est traitée. Elle ne l'est pas, sauf si votre équipe prolonge cette discipline au-delà du point où le workflow de Kiro s'arrête.

Ce qui change pour l'équipe

Le design se fait en public, pas dans des sessions d'agent privées

Dans un pipeline multi-agents, la décision de design est prise à l'intérieur du pipeline. Au moment où un membre de l'équipe la voit, soit elle est déjà implémentée, soit elle est consignée dans un fichier de sortie qui finira ou non par atterrir dans une pull request. Avec Kiro, le document de design est la première sortie commitée dans le dépôt, avant le démarrage de l'implémentation. L'équipe voit et relit le design au moment où il se construit, pas après.

Cela change directement la code review. Relire du code sans spec, c'est inférer l'intention à partir de l'implémentation, ce qui est lent et biaisé en faveur de remarques de style plutôt que de fond. Relire du code par rapport à une spec, c'est vérifier si l'implémentation satisfait les exigences énoncées et si les choix s'alignent sur le raisonnement documenté. Les revues deviennent plus rapides et plus substantielles.

Le travail en parallèle fait remonter les conflits tôt

Les pipelines multi-agents opèrent typiquement sur un seul contexte de tâche. Dans une équipe où plusieurs ingénieurs construisent en parallèle, chacun avec ses propres sessions d'agent ou ses propres pipelines, aucun mécanisme ne permet de détecter que deux features adoptent des hypothèses d'architecture contradictoires. Les specs de Kiro, commitées avant l'implémentation, fournissent le point de référence partagé qui rend ces conflits visibles au bon moment, avant que le code en conflit ne soit écrit.

La connaissance survit au turnover

Quand un ingénieur quitte une équipe qui pratiquait le vibe coding ou faisait tourner des pipelines d'agents non structurés, son contexte part avec lui. J'ai vu cela se produire assez souvent pour savoir comment ça finit : trois mois plus tard, quelqu'un fait de la rétro-ingénierie sur un service que personne ne comprend complètement. Les ADR et les specs du modèle Kiro sont rattachés au dépôt, pas aux personnes. Le raisonnement derrière chaque décision significative est là pour qui viendra ensuite, qu'il s'agisse d'un ingénieur arrivant dans trois mois ou d'une équipe héritant du système dans trois ans.

La question franche

Voici la question franche pour les équipes qui font tourner des pipelines multi-agents : votre pipeline produit du code. Savez-vous pourquoi il a été conçu de cette façon ? Votre équipe le sait-elle ? Le saura-t-elle dans six mois ? Si la réponse à l'une de ces questions est incertaine, vous accumulez une dette de connaissance qui va s'aggraver.

Cette dette suit une trajectoire prévisible : la vélocité se dégrade, l'onboarding ralentit, et finalement quelqu'un propose la réécriture — parce que modifier un système que personne ne comprend paraît plus risqué que de repartir de zéro.

Kiro ne remplace pas votre outillage multi-agents pour l'exécution de tâches bornées. Il fournit la couche structurelle (specs, ADR, Hooks, artefacts visibles par l'équipe et commités avant l'implémentation) qui transforme la sortie générée par l'IA en un logiciel que votre équipe peut réellement s'approprier.

La question du surcoût

Le workflow de spec ajoute du temps de planification avant l'implémentation. Pour un script éphémère ou une tâche d'automatisation bornée, ce surcoût n'est pas justifié. Certaines équipes constatent que l'approche structurée de Kiro sur-spécifie les problèmes simples, et que les points de validation ajoutent une friction qui paraît inutile pour des changements à faible enjeu.

L'équipe de Martin Fowler a examiné les outils de spec-driven development (Kiro parmi eux) et a conclu que l'approche opiniâtre à workflow unique n'est probablement pas adaptée à la majorité des problèmes de coding réels. Ils ont raison. La majeure partie du travail d'engineering au quotidien consiste à modifier des systèmes existants, à corriger des bugs et à faire des changements incrémentaux — du travail où un cycle de spec complet crée plus de friction que de valeur. La défense du spec-driven development repose sur le sous-ensemble de travaux où des décisions d'architecture sont prises et où le coût d'une erreur est élevé. Ce sous-ensemble est plus restreint que cet article ne le laisse peut-être entendre, mais c'est là que se nichent les erreurs les plus lourdes de conséquences.

Kiro propose à la fois les modes spec-driven et vibe coding dans le même IDE, et les deux coexistent bien : vibe coding pour l'exploration et le travail jetable, specs pour tout ce qui sera maintenu. La vraie question, c'est de savoir si les équipes appliquent ce jugement avec justesse. D'expérience, la tentation est d'utiliser la voie rapide pour tout et de se convaincre que la feature est plus simple qu'elle ne l'est. La majeure partie de la dette de connaissance dans les bases de code, c'est le résidu accumulé de cette décision, prise des dizaines de fois.

Une heuristique pratique : utilisez le mode spec dès que l'une de ces conditions est vraie — la feature touche un modèle de données, introduit une nouvelle intégration externe, franchit une frontière de sécurité, ou sera traitée par plus d'un ingénieur. Vibe coding pour tout le reste. Le coût d'une mauvaise décision d'architecture s'aggrave à chaque sprint qui suit ; le coût d'une sur-spécification d'un script jetable, c'est une heure de votre temps.

Pour les équipes qui adoptent le mode spec pour la première fois, une approche progressive réduit la résistance. Commencez par une nouvelle feature qui satisfait au moins deux des conditions heuristiques ci-dessus — assez de complexité pour rendre la spec utile, mais pas au point que la première expérience soit écrasante. Menez la revue de spec comme une vraie réunion de design : désignez quelqu'un pour challenger le document d'exigences avant approbation, pas seulement pour le lire. Une fois la première feature livrée, faites une courte rétrospective pour voir si la spec a permis d'attraper quelque chose qui aurait sinon émergé plus tard. Ce seul élément factuel — on a attrapé le problème de schéma en revue de design plutôt qu'en production — est plus convaincant pour une équipe d'ingénieurs sceptique que n'importe quel argument de processus.

Conclusion

La génération actuelle d'outillage de développement IA a largement résolu le problème de la production de code. Les outils savent transformer des exigences en langage naturel en implémentations fonctionnelles à une vitesse qui aurait paru improbable il y a trois ans.

Ce que la plupart d'entre eux n'ont pas résolu, c'est le problème d'équipe : comment un groupe d'ingénieurs construit-il du logiciel ensemble, avec l'assistance de l'IA, d'une manière qui produit une compréhension partagée plutôt qu'une sortie partagée que personne ne maîtrise vraiment ? Comment répondre à pourquoi cela a-t-il été conçu ainsi ? quand le design s'est joué dans une session d'agent que personne d'autre n'a vue ?

La réponse de Kiro est structurelle : produire les artefacts qui rendent ces questions traitables, avant que le code n'existe, comme partie intégrante du workflow. Les fichiers de spec donnent à l'équipe une visibilité sur l'intention de design. Les ADR, générés via un fichier de steering que vous configurez et tenus à jour par les Hooks, donnent à l'équipe une visibilité sur le raisonnement qui sous-tend les décisions. Les deux vivent dans le dépôt et transitent par les pull requests comme n'importe quel autre artefact de code.

Pour les équipes qui utilisent déjà des frameworks multi-agents pour des tâches d'exécution, Kiro n'est pas un remplacement. C'est la couche que ces outils ne fournissent pas : un workflow révisable, visible par l'équipe, qui capture les décisions et transforme le code généré par l'IA en logiciel qu'une équipe d'engineering peut maintenir.

Le problème d'exécution est en grande partie résolu. Le problème d'équipe ne l'est pas. C'est le problème qui mérite qu'on s'y attelle — et c'est celui sur lequel le reste de l'industrie de l'outillage n'a pas encore parié.