blog.vfg.lol

Triple modeles sur Cote Jardin : du conflit a la livraison

Comment un workflow Cursor/Ollama/Opus a transforme trois analyses concurrentes en plan executable, relecture fiable et skill reutilisable

Pourquoi ce workflow valait la peine

On avait trois modeles, trois voix, et un risque classique: produire trois documents convaincants mais incompatibles. Sur le lot J de Cote Jardin, l'objectif n'etait pas de choisir "le meilleur modele". L'objectif etait de sortir une livraison fiable sans perdre les angles morts des autres.

Le cadre de travail a ete simple: chaque modele livre un plan et un audit, puis on fusionne sous contraintes reelles de depot. Ensuite seulement, on execute. Et apres execution, on relit le code reel pour valider ce qui a ete annonce.

Ce n'est pas un benchmark marketing. C'est un protocole de decision.

Le probleme que les workflows mono-modele cachent

Un modele seul peut etre excellent et quand meme rater un type de risque:

  • tres bon sur bugs P0, faible sur operations;
  • tres bon sur operations, faible sur UX/documentation;
  • tres bon sur synthese, faible sur preuves recontrolees.

Le vrai cout arrive plus tard: conflits de perimetre, taches qui se chevauchent, baseline annoncee non reproductible, ou encore backlog pollue par des "fix" qui sont en fait des paliers humains non delegables.

Le workflow triple modeles force ces tensions a remonter tot, pendant que corriger le plan coute encore peu.

La methode en 7 phases

1) Cadrage

Avant de lire les plans, on fige:

  • les interdits depot;
  • les hors scope non negociables;
  • la baseline de verification du moment;
  • les paliers humains exclus des agents.

Ce cadrage evite les faux debats. Un modele peut proposer un chantier valide, mais s'il est hors lot, il ne part pas en vague agent.

2) Ingestion normalisee

Chaque modele est lu en separant strictement plan et audit. On capture ensuite les propositions dans une grille commune:

  • type (constat/recommandation),
  • niveau de preuve,
  • portee (lot/plateforme/humain),
  • conflit potentiel.

Cette normalisation est la cle: sans elle, la fusion devient un collage.

3) Registre de conflits

On redige un registre explicite "conflit -> decision -> rationale". Le but n'est pas d'avoir raison en theorie, mais de retenir ce qui est executable sous contraintes.

Exemples typiques:

  • recette liste dure vs lanceur glob;
  • HSTS long immediat vs progressif;
  • CSP publique immediate vs dette documentee;
  • monitoring vague 1 vs post-qualite.

Une fois tranche, on ne rouvre pas le conflit a chaque fiche.

4) Mega plan fusionne

Le mega plan doit contenir, sans ambiguite:

  • qui apporte quoi;
  • ce qui est retenu;
  • ce qui est ecarte et pourquoi;
  • l'architecture des vagues;
  • les gates humaines apres execution.

Sans ce document, la parallelisation devient un pari.

5) Decomposition T-

Chaque action retenue devient une fiche avec Possede explicite. La regle non-negociable: pas d'intersection intra-vague. Si intersection, on separe ou on sequence.

Deux effets immediats:

  • on peut lancer des agents en vrai parallelisme;
  • on reduit le nombre de conflits au merge.

6) Relecture post-lot

Apres execution, on relit en lecture seule le code reel des taches critiques. Pas les declarations, le code.

On classe alors les ecarts:

  • regression livree,
  • dette connue,
  • ecart cosmetique,
  • baseline non reproductible.

Ce point est vital: il coupe le biais d'auto-validation de la phase execution.

7) Comparatif modeles

Le comparatif n'est pas un podium. C'est un retour d'usage:

  • forces reelles de chaque modele,
  • faiblesses observables,
  • zones d'aveugle,
  • fiabilite des constats,
  • qualite de la fusion.

Ce que chaque modele a apporte sur ce cas

Le pattern qui ressort est net:

  • Opus a servi de colonne vertebrale corrective P0 (bugs mesurables, criteres de fin stricts, execution guidable).
  • Cursor a renforce l'hygiene qualite/docs (filet de coherence, points UX, lisibilite pour la suite).
  • Ollama a cartographie les risques operations (pipeline, sync, monitoring, dettes d'exploitation).

La valeur ne vient pas d'un vainqueur unique. Elle vient de la complementarite rendue actionnable par le registre de conflits.

Les deux decisions qui changent tout

Decision 1: separer coordination et execution

Le coordinateur garde:

  • index concurrence,
  • dispatch,
  • status,
  • arbitrages.

Les agents gardent uniquement leurs Possede. Ce split supprime une grande partie des collisions documentaires et des fermetures incoherentes.

Decision 2: refuser la confusion "probleme technique" vs "gate humaine"

Deploy, cron, restauration, bascule SEO, donnees client non confirmees: ces sujets peuvent etre critiques, mais ils ne deviennent pas des taches agent par simple pression de planning.

Ce tri protege la qualite et la responsabilite.

Ce qui a failli deraper (et ce qu'on a appris)

Le lot a montre une fragilite classique: une baseline annoncee peut devenir fausse une fois qu'un test se met a dependre d'un etat temporel.

Le bon reflexe n'est pas de "verdir" vite. Le bon reflexe est:

  1. signaler l'ecart,
  2. le classer correctement,
  3. ouvrir une suite dediee si necessaire,
  4. ne pas confondre avec regression livree.

Ce comportement preserve la confiance dans les rapports.

Industrialiser: skill + checklist + templates

La session ne s'est pas arretee au comparatif. On a extrait la methode en artefacts reutilisables:

  • une skill cote-jardin-triple-modeles;
  • une checklist de workflow;
  • des templates mega plan / fiches / handoff / comparatif;
  • un script de scaffold local pour lancer un nouveau lot sans toucher les docs officielles avant arbitrage.

Autrement dit: on a transforme une bonne session en procedure.

Quand utiliser (ou non) le triple modeles

A utiliser quand:

  • le lot est multi-axes (code + ops + docs),
  • plusieurs modeles sont disponibles,
  • les conflits de perimetre sont probables,
  • une trace d'arbitrage est requise.

A eviter quand:

  • une seule fiche locale est a corriger,
  • le cout de coordination depasse la complexite technique,
  • le perimetre n'est pas encore defini.

Conclusion

Le gain principal de ce workflow n'est pas "plus de texte". C'est une meilleure prise de decision sous contrainte.

Le triple modeles fonctionne quand on impose trois disciplines:

  1. normaliser les entrees,
  2. arbitrer explicitement,
  3. verifier apres execution.

Ce triptyque transforme une concurrence de documents en une chaine de livraison auditable. Et c'est exactement ce qu'on cherchait.

source markdown

Concepts de cet article

gatehandoffgarde

Partage le plus de concepts avec