thekb.eu — Stratégie & Frameworks

Loop Engineering for Product Managers

Sun, 21 Jun 2026 00:00:00 GMT

Dans cet essai long format publié sur X, **Shubham Saboo** soutient que la prochaine compétence décisive du Product Manager à l'ère des agents n'est pas le **prompt engineering** mais le **Loop Engineering**. L'état final n'est pas un PM écrivant le prompt parfait chaque fois qu'il a besoin de quelque chose, mais un PM **concevant un système qui s'améliore à chaque exécution**. Une boucle est un cycle répété : on modifie ce qui façonne le comportement de l'agent, on exécute, on évalue la sortie, on conserve le changement si la qualité progresse et on l'annule sinon, puis on **capitalise l'apprentissage** pour que la version suivante démarre en avance. Pour un ingénieur, ce cycle part du code. Pour un PM, il part des **artefacts** qui structurent le travail produit : skill de revue de PRD, *summarizer* d'appels clients, rubrique d'évaluation, checklist de lancement, workflow de recherche, `CLAUDE.md`, template de prompt, framework de priorisation. Durables et réutilisés, ils encodent le jugement et façonnent l'agent sur des dizaines de runs — donc ils **composent dans les deux sens**. C'est là qu'intervient le vrai problème : la **dérive**. Le CLAUDE.md s'allonge, la checklist enfle, les critères d'éval changent sans trace ; un mois plus tard l'agent « semble pire ». Le modèle n'a pas régressé : les artefacts ont dérivé sans surveillance, et c'est précisément ce que le Loop Engineering corrige. Une boucle utile a **cinq parties** : trigger, action, **preuve**, mémoire, **condition d'arrêt**. Cette dernière est la plus critique : beaucoup de systèmes échouent faute de sortie propre (scope qui enfle, résumé confiant sans preuves). Une bonne boucle doit pouvoir dire « stop » — rien n'a changé, input trop mince, bloqué, barre non atteinte, décision humaine requise. Mettre son jugement dans des artefacts réutilisables impose que le **goût** ait désormais une **preuve** : les **evals** deviennent du travail de PM, à partir d'exemples connus (3 bons / 3 mauvais PRD, 5 appels compris, 2 lancements passés). La question n'est plus « l'agent a-t-il l'air intelligent ? » mais « cet artefact s'améliore-t-il face à un jugement produit connu ? ». L'apprentissage a besoin d'une **mémoire** : **GitHub**, où vivent artefact, diffs, résultats d'éval, journal de décision et rollback — *« the repo becomes product memory »*. Saboo conseille de commencer petit, par les **ops produit** : un **weekly product signal loop** (chaque vendredi) produisant un memo qui sépare signal répété et bruit isolé. La boucle informe une décision que le PM **garde** : *« build the loop, but stay the PM »*. La génération est résolue ; restent la vérification et le jugement.

How the X Algorithm Actually Works in 2026 — and What That Means for Growth

Sat, 16 May 2026 00:00:00 GMT

Rapport interne de teardown du release open-source **`xai-org/x-algorithm`** (15 mai 2026) — l'algorithme **For You feed** de **X (ex-Twitter)** en 2026, avec quatre pistes de recommandations growth audience-tunées (personal/founder, brand/company, framework généralisé, livrable client/consulting). **Thèse-pivot** : ***« The famous 2023 weight table — replies count more than likes by a big multiplier — describes a system that no longer exists in this form. »*** L'algorithme 2026 est un **transformeur (Phoenix, dérivé Grok-1)** qui apprend les poids depuis ton historique d'engagement, scoré contre une **surface multi-actions à 19 dimensions**, gatée par un service offline de content understanding (**Grox**). **La forme du scoring importe désormais beaucoup plus que les nombres — et les nombres eux-mêmes ne sont pas dans le release public**. **Architecture en 4 composants** : (1) **Home Mixer** (Rust, orchestrateur request-time, hydrate → source → filter → score → select → filter) ; (2) **Thunder** (Rust, in-memory store Kafka-fed des posts récents, lookups sub-ms des candidats in-network) ; (3) **Phoenix** (JAX ML, retrieval two-tower + ranking transformeur, ~Grok-1 dérivé) ; (4) **Grox** (offline, classifieurs spam/safety/PTOS/banger + embedder multimodal v5). **Les 19 actions prédites par Phoenix** (changement-clé vs 2023) : favorite, reply, repost, photo_expand, click, profile_click, vqv (video quality view gated by min duration), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (continuous). **Score final** = `Σ (weight × P(action))` modifié par **3 multiplicateurs structurels** : (a) **OON_WEIGHT_FACTOR < 1** (pénalité out-of-network), (b) **author diversity decay** `(1-floor) × decay_factor^position + floor` (atténuation exponentielle des posts répétés du même auteur dans un même render), (c) **video duration gate** (vqv ne contribue que si `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Caveat capital** : **aucune valeur numérique des poids** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) n'est dans le release — tout est `crate::params::*`, géré par un feature-switch service interne X pour A/B testing. ***« Anyone telling you 'replies are worth N.N× more than likes in 2026' is fabricating a number that is not derivable from the OSS release. »*** **Différences-clés vs 2023** : (1) suppression de toute feature hand-engineered (*« We have eliminated every single hand-engineered feature and most heuristics from the system »*) ; (2) un seul modèle prédisant 19 actions vs plusieurs modèles 1 action chacun ; (3) Grox sépare content understanding et ranking ; (4) nouveaux signaux first-class (dwell continu, vqv gated, follow_author, 3 variantes de share) ; (5) two-tower OON retrieval (vs SimClusters+heuristics) avec embeddings multimodaux text+image+ASR-video. **Three layers of reach** (framework généralisé) : Eligibility (binary, Grox+filtres) → Retrieval (probabilistic, two-tower ANN) → Ranking (continuous, weighted-sum + multipliers). **Two laws of mechanical growth** : (1) In-network is multiplicative, OON is additive ; (2) The model's job is to predict you, not reward you. **Boundary d'honnêteté assumée** : checkpoint Phoenix released = mini (2 layers, 4 heads, 256-dim, corpus 537K posts sports), pas le modèle prod ; intégrations Thrift stubbées (`panic!("Not implemented")` dans `candidate_features.rs`) ; brand-safety lists, topic ID mappings, language penalties, ad-blending rules absents du public.

La Révolution AI4* : Analyse Stratégique de l'Impact de l'IA sur le Cycle de Vie de la Production Logicielle

Sat, 01 Nov 2025 00:00:00 GMT

Analyse stratégique deep research examinant transformation fondamentale industrie logiciel via concept "AI4\*" (AI for Everything): refonte systémique chaîne valeur production, processus artisanal haute intensité main-d'œuvre → paradigme industriel automatisé guidé intelligence. **6 piliers transformés par IA** **AI4Project** (Gestion Projet): Estimation prédictive basée données (Operum, Idealink génèrent plans minutes) vs "estimation doigt mouillé". Paradoxe: estimer projets IA eux-mêmes notoirement complexe - coûts cachés (données, talents 100-200k$/an, GPU) 20k$ chatbot → 500k$+ systèmes avancés. NIST AI RMF devient composant *central* planification (non plus facultatif) - gérer nouveaux risques (biais algorithmiques, failles sécurité code généré, transparence boîte noire). **AI4UX** (Interaction Humain-Machine): Design génératif (Uizard, Moonchild, Figma génèrent wireframes/UI via prompts langage naturel). Interfaces adaptatives personnalisation temps réel. "Utilisateurs synthétiques" (agents IA personas) testent prototypes vs recruter panels humains - retour information précoce. AI Design Framework redéfinit rôle concepteur UX: "créateur interfaces" → "architecte interactions humain-agent". **AI4Dev** (Développement): **Vibe Coding** (Karpathy février 2025) - langage naturel décrire objectif → IA génère code → expérimentation itérative. Abaisse barrière entrée (non-programmeurs construisent apps), prototypage ultra-rapide. MAIS **Vibe Coding Hangover** - code accepté "sans totalement compris", dette qualité/sécurité exponentielle, "enfer développement". Crée économie **"Vibe Check"**: CodeRabbit, Qodo agents revue IA "corriger bogues/défauts introduits vibe coding", scannent "AI slop". Nouveau rôle: développeur → "ingénieur guide". **AI4Ops** (Opérations): AIOps (Gartner 2016) applique IA automatiser opérations IT. Évolution 3 niveaux: (1) Maintenance Prédictive (IA alerte humain) → (2) Remédiation Automatisée (IA déclenche solution pré-écrite) → (3) **Opérations Autonomes/Systèmes Auto-Réparants** (objectif ultime: diagnostiquer/résoudre autonomément problèmes nouveaux sans intervention humaine). Plateformes: Dynatrace (opérations préventives), ServiceNow (Predictive AIOps), Splunk, New Relic, IBM, OpenText. **AI4Data** (Gouvernance): Dualité - gouvernance *prérequis* IA digne confiance ET *domaine* bénéficiant automatisation IA. "Governance *for* AI": données non gouvernées → IA biaisée/non conforme. "AI *for* Governance": découverte/catalogage automatiques, conformité automatisée (EU AI Act, GDPR), documentation/audit auto-générés, qualité/risque analyse continue. Exemples production Brésil: **Cielo** (IA agentique détection blanchiment/analyse chargeback autonome), **Zup StackSpot** (orchestration flottes agents IA cycle développement). **AI4Cloud** (Infrastructure): Double dychotomie FinOps. (1) "IA pour FinOps" - automatise right-sizing/détection anomalies/prévision dépenses. (2) **"FinOps pour IA"** (problème critique) - workloads IA profils coûts volatils/imprévisibles (GenAI formation/inférence/GPU). Nouvelles métriques (coût-par-token vs instance/heure), nouvelles contraintes (rareté GPU), nouveau modèle mental ("coût par résultat", "architecture frugale"). 5 stratégies optimisation: modèles, GPU (NVIDIA MIG, continuous batching), infrastructure (caching), données, commerciale (Savings Plans, Spot instances). **GenAI Landing Zone** - architecture référence intégrant 6 piliers fondation gouvernée (Foundation Guardrails, observabilité coût temps réel, sandboxes conformes, orchestration AWS Step Functions). **Tendance stratégique majeure transversale**: Transition **Copilotes → Agents autonomes** (main-d'œuvre agentique). Agents déployés détection fraude (Cielo), utilisateurs synthétiques testeurs UX, agents revue code, systèmes self-healing AI4Ops. **4 conclusions stratégiques interdépendantes**: (1) Paradoxe Vibe vs Check (vitesse génération crée dette qualité nécessitant gouvernance IA), (2) Avènement main-d'œuvre agentique (orchestration flottes agents), (3) Crise FinOps pour IA (coûts volatils goulot étranglement mise échelle), (4) Gouvernance chemin critique (fossé pilote-production = fossé gouvernance, GenAI Landing Zone intègre conformité/coût/sécurité par défaut). **4 recommandations CTOs/CIOs**: Investir gouvernance avant vitesse (garde-fous avant GenAI massif), résoudre crise FinOps maintenant (coût métrique conception, architecture frugale), préparer organisation agents (transformer rôles: développeurs→guides, UX→stratèges interaction, Ops→gestionnaires autonomes), centraliser pour évoluer (plateformes centralisées gouvernance + GenAI Landing Zone vs pilotes disparates).

The Gen AI Playbook for Organizations

Sat, 01 Nov 2025 00:00:00 GMT

Bharat N. Anand (NYU Stern Dean) et Andy Wu (Harvard Business School) présentent dans Harvard Business Review un framework stratégique pour déploiement IA générative au-delà de questions mal posées sur intelligence AI ou vitesse CIO, recentrant sur création avantage compétitif durable. **Questions mal posées vs vraie question stratégique** Les dirigeants posent les mauvaises questions : « Quand l'IA générative égalera-t-elle l'intelligence de mes meilleurs employés ? Est-elle assez précise ? Mon DSI avance-t-il assez vite ? Que font les concurrents ? » Ils se focalisent sur l'intelligence de l'IA et sa trajectoire au lieu des implications de stratégie d'entreprise. Vraies questions : « Comment l'organisation peut-elle utiliser l'IA générative efficacement DÈS AUJOURD'HUI, malgré ses limites ? Comment s'en servir pour créer un avantage concurrentiel ? » **Framework 4 quadrants** Les auteurs positionnent les tâches sur 2 dimensions : coût des erreurs × type de connaissance (explicite vs tacite). **No Regrets Zone** (faible coût d'erreur + connaissance explicite) : tri de CV, transcription de réunions, réponses de service client. Déployer immédiatement : vitesse + économies. **Creative Catalyst Zone** (faible coût d'erreur + connaissance tacite) : slogans marketing, variations de design, plans de présentation. L'IA générative amplifie la créativité humaine et élargit la participation. **Human-First Zone** (coût d'erreur élevé + connaissance tacite) : recrutement de dirigeants, définition de stratégie, gestion de crise. L'IA générative fournit une analyse de soutien, les humains conservent l'autorité de décision. **Quality Control Zone** (coût d'erreur élevé + connaissance explicite) : rédaction juridique, analyse financière, développement logiciel. Modèle human-in-the-loop : l'IA traite le travail intensif en données, les humains vérifient. **3 impératifs stratégiques** **Accès et expérimentation** : supprimer les goulots d'étranglement IT pour permettre l'expérimentation large par les employés, et non un déploiement piloté uniquement par l'IT. Démocratiser l'expérimentation vs contrôle centralisé. **Les données comme rempart concurrentiel** : centraliser les sources de données propriétaires, capturer de nouveaux flux de données. Donner à l'IA générative un savoir spécifique à l'entreprise difficile à répliquer par les concurrents. Seule défense contre la commoditisation d'outils identiques accessibles à tous. **Refonte organisationnelle** : repenser les structures autour des boucles de feedback sur les données, redéployer la main-d'œuvre. Traiter le temps libéré comme une ressource stratégique gérée plutôt que de supposer une amélioration automatique du compte de résultat. Le temps libéré ne devient pas automatiquement profit sans réallocation intentionnelle. **Paradoxe d'Accès : avertissement critique** Puisque les concurrents accèdent aux mêmes outils, l'avantage va à ceux qui déploient l'IA générative DIFFÉREMMENT — pas à ceux qui vont simplement plus vite. Citation clé : déployer différemment vs aller plus vite. Les organisations appliquant l'IA générative aux mêmes tâches s'exposent à la commoditisation. Clients et fournisseurs peuvent désintermédier les chaînes de valeur traditionnelles, comprimant les marges comme les cabinets juridiques l'ont vécu après les années 1990 (outils de recherche juridique démocratisés, accès direct des clients, intermédiaires sous pression). **3 sources de différenciation stratégique** « Strategic differentiation will come from three sources: (1) rapid deployment across tasks; (2) proprietary data; (3) unique people, processes, and culture. » La combinaison vitesse + données propriétaires + culture unique est la seule protection durable. Un outil accessible à tous ne crée pas d'avantage — c'est la manière de déployer, les données exclusives et la culture organisationnelle qui différencient. Article HBR classique transposant les frameworks de management stratégique (Porter, resource-based view) à la disruption de l'IA générative, formalisant les meilleures pratiques émergentes pour les dirigeants qui pilotent la transformation.

Votre nouveau super-pouvoir : voir le jeu dans son ensemble (Wardley Mapping Expliqué)

Wed, 01 Oct 2025 00:00:00 GMT

**Fondation Conceptuelle : Stratégie comme Jeu Dynamique** Document pédagogique expliquant Wardley Mapping comme outil **conscience situationnelle** pour navigation stratégique. Fondé sur prémisse que stratégie n'est pas plan rigide mais **art prendre décisions intelligentes dans environnement changeant constant**, analogie jeux stratégie temps réel (Fortnite, League of Legends) vs jeu dames prévisible. Référence Sun Tzu (2500 ans) : général nécessite 5 éléments victoire, **compréhension paysage étant la plus critique**. Sans carte précise champ bataille, même général courageux condamné échec. Simon Wardley créa méthode pour **rendre visible l'invisible** après erreurs stratégiques coûteuses par manque cartographie. **Architecture Carte : Deux Axes Fondamentaux** **Axe Y (Vertical - Chaîne Valeur)** : représente "qui a besoin de quoi". Règle simple : plus élément haut, plus **visible pour utilisateur final/proche objectif principal**. Analogie pizza : Utilisateur (haut) → Besoin (pizza délicieuse) → Composants (pâte cuite, sauce, fromage) → Dépendances invisibles (four, électricité). **Ancre** = besoin utilisateur haut carte (toujours point départ). Dépendances reliées verticalement, électricité four **absolument essentielle mais totalement invisible** personne mangeant pizza. **Axe X (Horizontal - Évolution)** : rend carte puissante. Représente **mouvement prévisible gauche→droite** causé par compétition offre/demande. **Quatre étapes évolution** : **(1) Genèse** (Far West) - nouveau, chaotique, imprévisible, échec fréquent, haute récompense potentielle ; **(2) Sur mesure** (Artisan) - construit spécifiquement, rare, avantage concurrentiel ; **(3) Produit** (Mall) - achetable "sur étagère", stable, versions concurrentes, compétition fonctionnalités/prix ; **(4) Marchandise** (Robinet) - service public/utility, attendu disponible, paiement usage, remarqué seulement si panne. Analogie musique : premiers MP3 (Genèse) → premier iPod (Sur mesure) → smartphones apps musicales (Produit) → Spotify/Apple Music (Marchandise comme eau robinet). **Dynamique Système et Anticipation** **Principe crucial** : "choses établies permettent nouvelles choses émerger". Quand composant **bas chaîne valeur devient marchandise** (ex: stockage cloud, puissance calcul), il **réduit drastiquement coût/effort construire ce qui en dépend**. Innovation Genèse haut chaîne (ex: app montage vidéo IA) possible **uniquement parce que** composants sous-jacents marchandisés. Carte n'est pas photo instantanée mais **modèle système en mouvement**. Observer ce qui devient marchandise aujourd'hui → prédire innovations possibles demain. Essence anticipation stratégique. **Avantages Stratégiques Décisifs** **Focus énergie** : carte montre clairement ce qui rend unique vs standard. **Avantage concurrentiel réel provient composants gauche** (Genèse/Sur mesure). Exemple YouTube : Idée vidéo + Contenu = seuls éléments différenciation. Passer 80% temps/énergie là. Caméra (Produit), Plateforme (Marchandise) → **ne jamais construire soi-même, gaspillage monumental**. Règle décision : **construire l'unique, acheter le produit, utiliser la marchandise**. **Anticipation opportunités** : mouvement prévisible gauche→droite permet prédictions. Exemple : outil "Montage vidéo IA" apparaît Genèse → anticiper qu'il deviendra Produit puis fonctionnalité base YouTube (Marchandise) → transformation workflow, gain temps. Carte aide **voir vague arriver de loin, surfer au lieu submerger**. **Communication alignement** : carte = **vision unique partagée paysage** pour toute équipe. Fin débats interminables basés opinions. Discussion concentrée carte représentant **réalité objective commune**. Aide profils différents (créatifs Genèse + organisateurs Marchandise) **comprendre collaboration contributions respectives**. **Leçon Pensée Critique** Pouvoir stratégique ne réside pas dans liste composants mais **compréhension position sur axe évolution**. Même action nécessite stratégie complètement différente selon position. "Construire site web" n'est pas stratégie en soi : en 1994 (Genèse) = acte pionnier ; aujourd'hui (Marchandise Squarespace) = souvent **perte temps/argent**. Carte force dépasser "quoi" pour concentrer "où" et "quand". **Bonne réponse dépend toujours contexte** - leçon fondamentale pensée critique fournie visuellement/intuitivement. **Application Universelle** Outil non réservé entreprises mais **instrument universel** pour quiconque veut avantage via conscience situationnelle supérieure : postuler universités, grandir abonnés TikTok, gagner concours robotique, planifier projet scolaire, monter équipe esports. Tous défis se déroulent **paysage concurrentiel** cartographiable. Message final : carte n'est pas diagramme, c'est **façon de penser** développant conscience situationnelle aiguë pour penser comme maître stratège.

HOW TECH COMPANIES MEASURE THE IMPACT OF AI ON SOFTWARE DEVELOPMENT

Tue, 16 Sep 2025 00:00:00 GMT

Cette analyse approfondie explore comment **18 grandes entreprises tech**, dont Google, GitHub, Microsoft et Dropbox, mesurent l'impact de l'IA sur le développement logiciel, face au défi de justifier des investissements croissants dans les outils de codage IA. Rédigé par Gergely Orosz et Laura Tacho (CTO de DX), l'article souligne que si **85 % des ingénieurs utilisent des outils IA**, beaucoup de leaders d'ingénierie peinent à en évaluer la valeur réelle, faute de métriques claires au-delà de mesures superficielles comme les lignes de code (LOC). **Message central : combiner les métriques** Une mesure efficace de l'impact de l'IA exige de **combiner les métriques d'ingénierie « core » existantes et de nouvelles métriques spécifiques à l'IA**. Les entreprises ne doivent pas abandonner les métriques traditionnelles comme le Change Failure Rate, le débit de PR, le temps de cycle des PR et l'expérience développeur, car l'objectif ultime de l'IA est précisément d'améliorer ces fondamentaux de la livraison logicielle. Ces métriques core doivent être suivies conjointement avec les taux d'adoption IA, la satisfaction (CSAT) vis-à-vis des outils, le temps gagné par ingénieur et la dépense IA. **Dropbox**, par exemple, a atteint **90 % d'adoption IA** et vu ses ingénieurs fusionner **20 % de pull requests en plus** avec un taux d'échec de changement réduit. **Segmentation et état d'esprit expérimental** Un aspect crucial est la **ventilation des métriques par niveau d'usage de l'IA** : comparer utilisateurs IA et non-IA, et analyser les tendances dans le temps. Ce découpage par rôle, ancienneté ou langage de programmation aide à identifier les groupes qui bénéficient le plus de l'IA ou nécessitent une formation supplémentaire. L'article insiste sur l'**état d'esprit expérimental**, où les données servent à répondre à des questions précises et à tester des prédictions sur l'influence de l'IA. **Qualité, maintenabilité, expérience développeur** La vigilance sur la **qualité du code, la maintenabilité et l'expérience développeur** est primordiale. Les auteurs avertissent que le développement assisté par IA peut créer « le plus gros tas de dette technique » s'il n'est pas géré avec soin. Il est essentiel de suivre des métriques qui se contrôlent mutuellement, comme la vitesse avec la qualité (débit de PR et CFR). Au-delà des métriques système, les données auto-déclarées sur la « confiance dans les changements », la « maintenabilité du code » et la « perception de la qualité » sont vitales pour capturer les impacts de long terme. L'expérience développeur, souvent réduite à tort à des avantages superficiels, est critique pour réduire la friction sur tout le cycle de développement. **Tendances émergentes et défis** Microsoft utilise les **« bad developer days » (BDD)** pour évaluer l'impact de l'IA sur la pénibilité quotidienne, tandis que Glassdoor mesure les résultats d'expérimentation (tests A/B). Le **taux d'acceptation** des suggestions IA, autrefois métrique de référence, décline car trop étroit : il ne capture ni la maintenabilité, ni l'introduction de bugs, ni la productivité globale. L'analyse des coûts, encore peu pratiquée pour ne pas décourager l'usage, devrait être davantage scrutée à mesure que les budgets IA croissent. La **télémétrie d'agents** et la mesure au-delà de l'écriture de code sont identifiées comme des domaines appelés à évoluer fortement. **AI Measurement Framework et couches de données** L'article introduit l'**AI Measurement Framework**, ensemble recommandé de métriques mêlant métriques IA et métriques d'ingénierie core, avec l'expérience développeur au centre. Il préconise une collecte de données en couches : données système quantitatives (outils IA, GitHub, JIRA, CI/CD), enquêtes périodiques qualitatives et échantillonnage d'expérience sur le moment. L'expérience de **Monzo Bank** sert d'étude de cas : la mesure objective est difficile (rétention des données par les fournisseurs), mais le ressenti subjectif des ingénieurs et des cas d'usage précis comme les migrations de code démontrent une valeur claire.

Context Engineering Needs Domain Understanding

Wed, 23 Jul 2025 00:00:00 GMT

L'article « Context Engineering Needs Domain Understanding » de Rod Johnson introduit le **Domain-Integrated Context Engineering (DICE)** comme une évolution du context engineering pour construire des applications LLM plus efficaces et robustes. Johnson commence par reconnaître le « context engineering » comme une avancée précieuse par rapport au « prompt engineering », le définissant comme l'art et la science de remplir la fenêtre de contexte du LLM avec les informations pertinentes. Il soutient néanmoins que cette définition est incomplète, car elle néglige deux aspects cruciaux : la nature bidirectionnelle de la communication avec les LLM (ce qui est envoyé *et* ce qui est reçu) et l'intégration des applications LLM avec la compréhension métier et les systèmes existants. **DICE : extension conceptuelle** Pour combler ces lacunes, Johnson propose DICE, qui étend le context engineering en mettant l'accent sur l'usage d'un modèle de domaine pour structurer le contexte et en considérant les sorties des LLM en plus des entrées. L'idée centrale : bien que les LLMs excellent en langage naturel, **ajouter de la structure aux entrées et sorties** les rend plus sûrs et plus fiables. DICE permet aux LLMs de « converser » en utilisant la terminologie et les concepts établis d'un métier, favorisant une meilleure intégration avec les applications existantes. Les domain objects, dans ce contexte, ne sont pas de simples structures de données mais définissent des comportements ciblés exposables au code écrit manuellement ET aux LLMs comme outils. **Bénéfices convaincants de DICE** L'article met en avant plusieurs bénéfices convaincants de l'adoption de DICE. Premièrement, il permet d'utiliser du code pour structurer le contexte, transformant un « art délicat » en processus plus scientifique où le contexte peut être affiné, raisonné et testé. Cela permet aussi un filtrage précis du contenu, améliorant les résultats et économisant des tokens. Deuxièmement, DICE facilite une intégration plus simple et plus sûre avec les systèmes existants, dépassant les applications Gen AI « de démonstration » vers des scénarios réels où les agents doivent accéder aux fonctionnalités existantes. En travaillant avec des domain objects, les entreprises peuvent réutiliser leurs modèles de domaine existants et capitaliser sur une compréhension métier durement acquise. **Avantages additionnels** D'autres avantages incluent une livraison accélérée et une qualité améliorée grâce à la réutilisation des modèles de domaine entre applications et agents. DICE offre aussi des options de persistance structurée, permettant une récupération plus précise via des technologies existantes comme SQL ou Cypher, complément potentiel à la recherche vectorielle. La structure et l'encapsulation ajoutées par le modèle de domaine renforcent la testabilité, le débogage et le traçage, car l'information apparaît dans les outils d'observabilité sous un format structuré et compréhensible. Enfin, l'intégration du domaine aide à gérer le contexte dans les flux multi-étapes, prévenant la dégradation de qualité et maîtrisant les coûts de tokens. **Positionnement stratégique** Johnson conclut que l'intégration du domaine est primordiale pour libérer la pleine valeur métier de l'IA générative, positionnant les applications métier existantes comme l'adjacence clé de la Gen AI, plutôt que la seule data science ou les LLMs eux-mêmes. **L'argument central** : la structure du modèle de domaine fait passer les capacités des LLM de puissantes-mais-chaotiques à contrôlées-et-fiables, condition essentielle de l'adoption en entreprise. En conceptualisant les domain objects comme des entités porteuses de comportements exposables comme outils, DICE comble le fossé conceptuel entre le potentiel des LLM et la réalité de l'entreprise, offrant un cadre pour une intégration Gen AI systématique, fiable et créatrice de valeur dans les workflows métier existants. Cette perspective pragmatique reconnaît que **la valeur de la Gen AI ne réside pas dans l'isolement**, mais dans l'intégration harmonieuse avec les systèmes éprouvés où réside la connaissance du domaine.

AI Workflow for Creating Wardley Maps (Video Tutorial)

Wed, 23 Apr 2025 00:00:00 GMT

**Objectif et contexte méthodologique** Tutoriel vidéo démontrant un workflow pratique utilisant l'IA (LLM) pour amorcer la création d'une Wardley Map. L'auteur, product manager dans le domaine ERP/Business Intelligence, cherche à explorer un espace produit et à obtenir rapidement un bon point de départ plutôt que de partir d'une feuille blanche. L'approche reconnaît que le Wardley Mapping manuel est long et complexe, et propose une automatisation partielle pour accélérer la phase initiale d'exploration stratégique. **Architecture technique : stack et outils** Le workflow repose sur **quatre composants** : **(1) l'API OpenAI** pour générer capacités et relations via des prompts structurés ; **(2) Obsidian** comme outil de gestion des connaissances exploitant son graphe de relations natif ; **(3) Python avec la bibliothèque NetworkX** pour l'analyse de clustering de type graphe social ; **(4) un frontend maison** (optionnel) pour faciliter la saisie des prompts et capacités. L'intégration fluide permet de passer les sorties JSON du LLM directement dans Obsidian, puis de les exporter vers Python pour analyse avancée, puis de réimporter les données enrichies dans le canvas Obsidian. **Trois prompts séquentiels structurés** **Prompt 1 - Décomposition des capacités** : format strict « I'm product manager for [product] in [space]. Frame capabilities as 'the ability to [blank]'. Break down capabilities using '... is a function of the ability to...' Return results in JSON. » Exemple concret : « buy lunch for team » (capacité de premier niveau) décomposée automatiquement en sous-capacités : planifier des repas équilibrés, sourcer des ingrédients de qualité, préparer efficacement les repas, s'adapter aux préférences/allergies. La décomposition crée des **relations hiérarchiques parent → enfant** automatiquement liées dans le graphe Obsidian. **Prompt 2 - Positionnement sur l'axe Y** : les Wardley Maps utilisent un axe Y représentant la proximité au client (haut = visible pour le client, bas = infrastructure abstraite/invisible). Le prompt catégorise les capacités selon leur proximité avec différents rôles d'une chaîne de valeur orientée excellence opérationnelle : **(niveau 1)** leaders excellence opérationnelle, COO, program managers stratégiques ; **(niveau 2)** coachs, designers ; **(niveau 3)** ingénieurs opérations/IT ; **(niveau 4)** ingénieurs plateforme et data ; **(niveau 5)** couches infrastructure/utilitaires. Point crucial : **toujours demander la justification** avec l'assignation du niveau. Cela permet de « rentrer dans le raisonnement du LLM » et facilite un réglage itératif. L'auteur souligne que ce prompt a nécessité un réglage en coulisses pour son domaine spécifique. **Prompt 3 - Relations entre capacités** : « Étant donné une liste de capacités (chacune avec ID, nom, description), identifier les relations significatives. Soit fonctionnellement similaires, SOIT habilitantes. Être très précis. Retourner du JSON avec : paire (deux IDs de capacités liées), type (similar/enables), raison (explication claire). » Stratégie : **insérer les capacités au hasard**, analyse stricte, comme scanner un tableau et tracer des lignes entre éléments similaires. Exemple de sortie : « analyze data insights » ↔ « trend analysis » = similaires (toutes deux centrées sur l'analyse de données) ; « analyze data insights » habilite « actionable intelligence » (dérive de l'intelligence des motifs de données). Cela enrichit les relations au-delà de la simple hiérarchie parent-enfant. **Clustering NetworkX et canvas final** Après la création des capacités, des relations hiérarchiques, des relations de similarité/habilitation et des niveaux sur l'axe Y, le workflow utilise la **bibliothèque Python NetworkX** (standard de l'analyse de graphes sociaux) pour **identifier des clusters au sein de chaque niveau**. L'analyse de la densité des connexions, comme dans un réseau social, assigne des IDs de cluster. Résultat : chaque capacité possède **(1) un niveau sur l'axe Y** (proximité client), **(2) un ID de cluster** (regroupement logique au sein du niveau), **(3) des liens parent-enfant**, **(4) des liens de similarité/habilitation avec justifications**. Les données enrichies sont importées dans le **canvas Obsidian** où les capacités sont visualisées. L'auteur utilise la **fonction de regroupement** d'Obsidian pour la lisibilité. Le clustering NetworkX produit parfois des regroupements sensés (exemple : « entrées horodatées, pistes d'audit des actions clés, préservation des données historiques » regroupées ensemble). **Navigation dans la chaîne de valeur et philosophie du bootstrap** Le canvas permet la **navigation dans la chaîne de valeur** : exemple « un leader veut de la priorisation » (haut de la carte) → descendre la pile niveau par niveau → identifier les différents éléments impliqués dans la priorisation. Démonstration concrète de la façon dont un besoin de haut niveau se décompose en capacités progressivement plus abstraites/infrastructurelles. **Leçon clé** : l'auteur insiste : « ce n'est que le début, juste pour amorcer ». La sortie de l'IA n'est pas la carte finale mais un **point de départ accéléré**. L'intention : « passer ensuite beaucoup de temps à apprendre le domaine en profondeur ». L'IA réduit la friction initiale de la page blanche et permet au product manager de commencer immédiatement l'itération et le raffinement avec une structure de base solide, plutôt que des semaines de cartographie manuelle. **Implications méthodologiques** Le workflow démontre une **augmentation pragmatique par l'IA** : ni stratégie entièrement automatisée (impossible vu la nuance et le contexte), ni entièrement manuelle (trop lente). L'approche hybride exploite les forces du LLM (reconnaissance de motifs, décomposition logique, identification de relations) tout en reconnaissant que l'expertise humaine reste indispensable pour la validation, le réglage des prompts (via les justifications) et l'apprentissage approfondi du domaine après le bootstrap. Les justifications systématiques créent une **boucle de rétroaction** permettant au praticien de comprendre le raisonnement du LLM, d'ajuster les prompts itérativement et d'améliorer la qualité des sorties. **Transférabilité au-delà du Wardley Mapping** Bien que centrées sur les Wardley Maps, les techniques sont généralisables : décomposition de capacités, catégorisation par proximité, identification de relations et analyse de clustering s'appliquent à d'autres frameworks stratégiques nécessitant une pensée structurée sur les chaînes de valeur, les dépendances et les couches d'abstraction. La stack Obsidian + NetworkX + API LLM est particulièrement puissante pour les travailleurs du savoir explorant des domaines complexes.