Support de talk de **Dorra Bartaguiz** (CTO, **Arolla**), présenté à la conférence **Dev With AI** et publié en PDF sur LinkedIn le **15 octobre 2026** ; **61 slides**, en français avec des exemples en anglais. Thèse : quand l'IA fait exploser la vélocité, la qualité se reprend par les pratiques *craft* outillées autour du modèle, le *harness engineering*.
#harness engineering#vélocité#revue de code
Dorra Bartaguiz — CTO d'Arolla (conseil et formation, « agentic software crafters ») ; slides de son talk Dev With AI publiées sur LinkedIn.
Billet de **Rachel Laycock**, CTO de **Thoughtworks**, publié le **2 septembre 2026** sur *Rachel's Ramblings*, la section de martinfowler.com qu'elle tient, environ **8 000 caractères**. Le texte est une **réponse assumée** à [[houck-dx-what-are-code-reviews-for-2026-08-05]], après un désaccord public entre les deux auteurs sur un panel de **Code Remix** hébergé par **Moderne**. Laycock accepte le diagnostic chiffré de Houck (+**106 %** de lignes par diff chez **Meta**, +**64 %** de taille médiane de PR côté DX) et la liste des fonctions non-défectologiques de la revue, puis déplace la question : *« why are we waiting until code review to do all of those things? »* (A) Le principe directeur est le raccourcissement des boucles de rétroaction appris chez Thoughtworks — si un retour a de la valeur, ne pas le supprimer, le rapprocher de la décision qu'il informe. Chaque fonction attribuée à la revue est réaffectée en amont : exploration d'alternatives avant l'implémentation, transfert de connaissance par le **pair programming**, propriété collective par le **mob programming** et les sessions de design d'équipe, alignement architectural par le design commun puis les **fitness functions**, et automatisation de tout ce qui est déterministe — *« We really shouldn't still be arguing about whitespace in 2026. »* (B) La revue par exception remplace la revue systématique : changement architectural fondamental, frontière de sécurité sensible, rayon d'impact large, zone inconnue d'un système critique, ou simple déclaration d'inconfiance de l'équipe. (1) L'automatisation de la revue par un agent qui imite le relecteur humain est écartée comme *« automating the ceremony rather than questioning why the ceremony exists »*. (2) La dette cognitive de Houck est reconnue comme réelle, mais la PR obligatoire est jugée une défense faible : *« We need engineers to understand systems, not diffs. »*
#revue de code#revue par exception#pull request
Rachel Laycock · CTO de Thoughtworks · sur *Rachel's Ramblings* (martinfowler.com).
Essai de **Bill Staples**, directeur général de **GitLab**, publié le **24 août 2026** sur le blog about.gitlab.com : **31 minutes** de lecture annoncées, environ **39 000 caractères**, présenté comme la suite d'un mémo écrit au conseil d'administration en janvier 2026 et partiellement publié en mai sous le titre *GitLab Act 2*. Le texte se donne comme une réponse au playbook AI-native SDLC d'**Anthropic** paru trois jours plus tôt, dont il reprend la phrase d'ouverture — *« Code is no longer the bottleneck »* — pour poser la question qui l'occupe : qu'est-ce qui devient rare quand le code devient abondant. (A) Le diagnostic économique : l'unité utile n'est pas le coût par ligne mais le **coût par changement accepté**, qui agrège génération, environnement, contexte, vérification, revue, remédiation et gouvernance ; l'IA effondre le seul terme de génération, ce qui rend les autres proportionnellement plus lourds — une organisation dix fois plus rapide à générer *« will simply move the queue »*. (B) La réponse architecturale : quatre capacités — plateforme d'agents, exécution à l'échelle machine, contexte durable, gouvernance — formant une couche d'entreprise qui survit au modèle, *« The model should be replaceable. The agent should belong to the customer. »* (1) Trois modes coexistent durablement, du légataire piloté par l'humain au développement autonome, contre l'idée d'une courbe de maturité unique. (2) Le pipeline CI/CD devient le lieu où tourne la boucle interne, au lieu d'être une porte en fin de course. Les chiffres avancés sont ceux de **Stripe**, **Spotify** et **Amplitude** ; GitLab n'en produit qu'un, sur son propre contrôle de source. Le corpus tient déjà [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], la source à laquelle ce texte répond, et [[sfeir-sdlc-pdlc-articulation-2026-07-22]] sur l'articulation SDLC/PDLC que Staples reprend à son compte.
#abondance du code#coût par changement accepté#théorie des contraintes
Bill Staples · directeur général de GitLab (fonction non affichée par la page) · sur le blog about.gitlab.com.
Décryptage SFEIR (voix cabinet) du REX de Jason Clinton (Deputy CISO, Anthropic) publié cinq jours plus tôt — déjà fiché en [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]]. **La valeur ajoutée n'est pas dans les faits, elle est dans la thèse qui les relit** : si les contrôles d'Anthropic tiennent, c'est parce qu'il existe **un cycle avec des étapes nommées où les accrocher** — « le SDLC est le socle, pas la formalité ». Démonstration par la relecture du mapping (**PSR au Plan, CLAUDE.md + egress allowlist au Code, agents de revue au Test, DAST continu au Deploy, triage + routage SIEM au Monitor**) puis par une **anaphore en quatre temps** : (1) *sans SDLC, les gains de productivité n'arrivent pas* — Clinton cite **Amdahl**, multiplier par 8 le volume de code ne multiplie rien si la revue reste séquentielle et humaine, et Anthropic n'a pas gagné en distribuant des agents mais en **identifiant l'étape qui bloquait (le Test) et en la reconstruisant** — « on n'optimise pas un goulot qu'on n'a pas cartographié » (renvoi à l'**effet miroir** de DORA 2025) ; (2) *sans SDLC, la sécurité n'a pas de point d'ancrage* — un **gate est par définition un contrôle placé entre deux étapes**, et les trois menaces de Clinton se traitent à des moments distincts ; (3) *sans SDLC, aucune politique **FinOps token** n'est formulable* — le scan agentique est facturé à la consommation et croît avec le débit de code, donc **le tiering par risque EST la politique FinOps** (il décide où l'on paie trois passes d'agents et où un SAST suffit), sinon « la dépense en tokens n'est pas pilotée, elle est constatée en fin de mois » ; (4) *sans SDLC, il n'y a rien à mesurer* — les indicateurs (16 % → 54 % de PR commentées, un tiers des incidents passés interceptés) n'existent que parce qu'il y a des étapes où poser un compteur, faute de quoi on ne produit que des **chiffres d'usage** (licences, tokens) muets sur la qualité et le risque. Deux points forts hors thèse : la lecture de **l'incident agent-à-agent** (« un périmètre de sécurité qui repose sur une consigne dans un prompt n'est pas un périmètre » ; **l'accès d'un agent aux autres agents fait partie de sa surface d'attaque**) et une **réserve méthodologique explicite** — chiffres d'Anthropic sur Anthropic, non audités, publiés par le vendeur du modèle décrit, dans un contexte de base de code jeune sans mainframe : **ce qui se transpose, c'est la méthode, pas les chiffres**.
#SDLC#SDLC AI-native#cycle de développement
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — commentaire de Jason Clinton (Deputy CISO, Anthropic)
Décryptage SFEIR (voix cabinet, « lecture d'ingénieurs ») articulant deux cadres trop souvent confondus : le **SDLC** (Software Development Life Cycle — *construire le logiciel correctement et de façon fiable*) et le **PDLC** (Product Development Life Cycle — *construire le bon produit et réussir sur le marché*). Thèse centrale : les deux cycles ne sont pas concurrents mais **emboîtés** — le SDLC est le sous-ensemble du PDLC **logé sous sa phase développement** ; quand une équipe produit atteint le stade « build », un cycle SDLC complet (conception → build → tests → revue → déploiement) s'exécute à l'intérieur. Le SDLC est normé (**ISO/IEC/IEEE 12207**, éditions 2017 et 2026), avec sa lignée de modèles (Waterfall 1970, cycle en V, itératif/spirale, **Agile 2001**, **DevOps/DevSecOps 2009+**) et ses métriques **DORA** (débit, stabilité, MTTR, change failure rate). Le PDLC, englobant, va de l'**idéation/discovery** au **retrait du marché** (à ne pas confondre avec le **PLC** marketing de Theodore Levitt, 1965, qui décrit une *courbe commerciale*, pas un *travail organisé* : « le PLC observe une courbe ; le PDLC organise un travail »). **Point de bascule** : le SDLC ne traite nativement **qu'un risque sur quatre** — via le cadre des **« Four Big Risks » de Marty Cagan** (Valeur → PM, Utilisabilité → Designer, Faisabilité → Lead Engineer, Viabilité business → PM), une organisation excellente en SDLC mais aveugle au PDLC produit « du logiciel dont personne ne veut » — la **« feature factory »** de John Cutler (succès mesuré à l'output, pas à l'outcome). **Pourquoi l'IA change tout** : l'IA générative **comprime le SDLC** (données Google/JetBrains mai 2026 : **~85 % des devs** utilisent régulièrement des agents de code, **~41 % du nouveau code** est généré par IA ; implémentation de semaines → heures), donc le **goulot d'étranglement se déplace vers l'amont** — décider *quoi* construire (Marty Cagan, avril 2026 : « quand le coût du delivery s'effondre, le goulot se déplace vers la discovery »). Conséquences : DORA 2025 (~5 000 pros, 90 % d'adoption IA) montre une **corrélation positive au débit mais négative à la stabilité** (plus de features non validées = instabilité + retravail) ; Andrew Ng (AI Startup School, juil. 2025) rapporte des équipes **inversant le ratio « 1 PM pour 4 ingénieurs » vers « 2 PM pour 1 ingénieur »** ; et avec le **spec-driven development**, la frontière PDLC/SDLC devient **poreuse** (la spec produit devient directement exécutable par des agents). **Ce qu'une DSI doit en retenir** : un SDLC augmenté devient **norme de marché, pas différenciateur** — il faut instrumenter la jonction avec le produit, exiger des **spécifications exécutables** en entrée, croiser métriques techniques et métriques d'outcome, et **refuser le rôle de « fournisseur de features »**. Pour un CPO : le déplacement du goulot vers la discovery est à la fois **promotion** (le jugement produit redevient rare) et **mise en demeure** (industrialiser la discovery pour atteindre la parité avec le SDLC). Le cadre maison SFEIR (« Concevoir et fabriquer à l'ère de l'agentique » — **cycle à 11 phases** + **Software Factory 10x**) est positionné comme réponse au versant ingénierie, le levier suivant étant l'**articulation des deux cycles**. Conclusion : « à mesure que le code devient une commodité, la marge se déplace vers le jugement produit et la gouvernance ».
Post LinkedIn de Fred Plais (CEO d'Archie, ex-Platform.sh) : l'IA a rendu les ingénieurs si rapides que le **goulot d'étranglement s'est déplacé en amont**, là où personne ne regarde. L'exécution n'étant plus la partie lente, le temps de réflexion qui existait « pendant que le code se construisait » a disparu — il faut désormais avoir la bonne vision et prendre les bonnes décisions en une fraction du temps. Deux profils rares émergent : celui qui sait **formuler une vision assez précise** pour qu'un agent l'exécute sans dérailler, et celui qui sait **orchestrer les agents** (anticiper leurs échecs, les chaîner, rattraper une erreur avant qu'elle se propage). Recruter pour le « code output » devient obsolète : c'est précisément ce qui a cessé d'être rare. Thèse finale : « penser clairement a toujours été le métier — la vitesse a juste rendu impossible de faire semblant ».
#goulot d'étranglement#déplacement du bottleneck#vitesse d'exécution