Architecture logicielle et construction des systèmes à l'ère de l'IA.
Article SFEIR (en français) qui formalise un **SDLC piloté par l'IA en 11 phases (0 à 10)** et soutient que l'industrie y converge. Constat de départ : en 2025, les organisations ont ajouté des outils IA sans transformer leur modèle opératoire — d'où un paradoxe « tout change… et rien ne change » (la vitesse d'exécution se multiplie sans gain proportionné). La vraie réponse n'est pas le choix d'outils mais la **refonte du cycle** pour une exécution machine. Le cycle SFEIR repose sur **trois portes humaines inamovibles** (Define, Plan, Ship), des phases automatiques entre elles, et **deux moments de capitalisation** (Compound-1 pré-déploiement, Compound-2 en production) qui transforment les leçons en règles réutilisables. Trois principes : l'**IA exécute** (artefacts complets + preuve d'exécution, jamais de confiance aux déclarations de l'agent), l'**humain garde le contrôle de l'intention**, le **système apprend cumulativement**. Résultats mesurés (refonte 6 mois→1 jour, **−30 % d'itérations** après dix cycles) et convergence revendiquée avec ADLC, Google et DORA 2025.
#SDLC#cycle de développement#IA
SFEIR
Papier arXiv (cs.SE) de Martin Monperrus défendant une thèse radicale pour le SDLC : les agents de codage ont franchi un seuil de capacité tel que **la revue de code humaine n'est plus un composant nécessaire** d'un pipeline qualité. Deux affirmations : (1) des systèmes autonomes à base de LLM atteignent tous les objectifs de la revue (détection de défauts, qualité, conformité) à coût moindre et débit supérieur ; (2) le modèle hybride « l'agent écrit, l'humain relit » est intenable — il n'assure pas une vraie qualité et ne passe pas à l'échelle de la vélocité IA, créant une « fausse sécurité ». Monperrus oppose à l'inspection de Fagan (1976) un **pipeline de vérification adversariale multi-agents** (agent générateur + agents reviewers indépendants + tests/méthodes formelles + consensus par vote). L'humain se recentre sur la spec, les arbitrages d'architecture, l'approbation des domaines critiques et les cas limites. Recommandations : piloter d'abord sur composants à faible risque, mesurer agent vs humain, expliciter les décisions de rejet.
#revue de code#code review#inspection de Fagan
Martin Monperrus
Philippe Ensarguet (Orange) soutient que cinquante ans de design patterns forment une lignée continue : à l'heure où l'IA banalise le code et casse l'apprentissage traditionnel des architectes, la « pattern literacy » (lire un système par ses forces invariantes) devient la compétence durable à enseigner — comme une grammaire, pas comme des catalogues.
#design patterns#lignée des patterns#architecte logiciel
Philippe Ensarguet
Guide d'Augment Code (Paula Hingel) décrivant comment les agents IA restructurent le cycle de vie logiciel (SDLC), stage par stage. Thèse : l'IA produit **plus de débit sur certaines étapes et plus de risque d'instabilité sur d'autres** — symptôme d'une adoption inégale sans redessiner les frontières de revue. Appui sur le **DORA 2025** : l'adoption IA est positivement corrélée au débit de livraison et à la performance produit, mais **négativement à la stabilité**. Six étapes revisitées (Requirements, Design/Architecture, Implementation, Testing/QA, Deployment, Maintenance), trois risques majeurs (érosion du pipeline junior, **validation circulaire** des tests IA, lacunes de gouvernance à l'échelle) et trois rôles émergents (**Intent Engineering**, Agentic DevOps, AI Governance/Assurance). Recommandations actionnables : auditer une étape avant de scaler, stress-tester la gouvernance, rendre la **spécification** centrale, définir des politiques de rollback explicites, redessiner le rôle des juniors autour de la revue.
#SDLC#cycle de vie logiciel#agents de codage
Paula Hingel (Augment Code)
Article d'ingénierie publié sur le blog d'**Uber** par six ingénieurs (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) le **21 mai 2026**, exposant la **doctrine d'identité et de contrôle d'accès des agents IA** déployée en production chez Uber pour plusieurs milliers d'agents internes. **Thèse-pivot** : les modèles d'identité existants (humains + workloads) ne décrivent pas l'**agency** — *« an agent is best defined as an entity that is authorized to act for or in the place of another »* — et perdent la **provenance** à travers les hops d'un workflow agentique. **Deux problèmes opérationnels identifiés** : (1) ***« Current Identity Model Doesn't Describe Agency »*** — la délégation est le mode par défaut, les workflows sont compositionnels (agents qui appellent agents qui appellent tools), le comportement est dynamique (plans évoluent selon résultats intermédiaires) ; (2) ***« Original Provenance Isn't Effectively Carried Forward Across Agents to Systems »*** — *« Execution context (originating user, intermediate agents) is dropped across agent hops. »* **Architecture proposée** comme extension de la Zero Trust Architecture Uber : **Agent Registry** (source of truth des mappings agent↔workload) + **AI Agent Mesh** (data plane inter-agents) + **STS (Security Token Service)** (émission JWT scopés courts) + **MCP Gateway** (policy enforcement point pour invocation d'outils) + **AI Gateway** (médiation appels LLM externes avec guardrails) + **SPIRE** (provider de workload credentials). **Mécanique cryptographique** : workloads récupèrent des **SVID (SPIFFE Verifiable IDs)** signés cryptographiquement depuis SPIRE → SDK demande JWT au STS via identité workload → STS vérifie l'autorisation agent contre Agent Registry → token court (TTL en minutes) émis pour **destination single-hop spécifique** (claim `Audience` ciblé). **Doctrine pivot** : ***« Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes. »*** **Préservation de la chaîne d'acteurs** : exemple multi-hop avec on-call engineer `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway ; le JWT final transporte l'**actor chain `[user1, oncall-agent, investigation-agent]`** vérifiable, permettant des décisions d'accès tool-level basées sur l'**historique complet de la requête**. **Standardisation** : **Standardized A2A (Agent-to-Agent) Client** qui automatise les échanges STS et la propagation de l'actor chain — *« the secure path is also the easiest path for developers to implement A2A calls »* — migration phasée des agents legacy. **Métriques production** : ***« P99 latency for the STS Token Exchange API is consistently below 40 milliseconds »***, milliers d'agents internes adoptés, dashboard d'observabilité temps réel traçant les sessions multi-agents. **Vision long terme — three-layer framework** : (1) Identity & Trust Foundation (identité agent vérifiable + delegation chains), (2) Dynamic Access Control (permissions context-based + human-in-the-loop), (3) Unified Enforcement Plane (politique centralisée observable). **Alignement standards** : IETF **WIMSE** working group + draft `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, basé conceptuellement sur **OAuth 2.0 Token Exchange (RFC 8693)** et **SPIFFE/SPIRE** (graduated CNCF). Première publication de référence d'un hyperscaler non-AI-lab (logistique/mobilité) qui industrialise la sécurité des agents au niveau infrastructure, comblant le gap doctrinal entre les frameworks de skills/harness (Vincent, Lattice, PROJ-AI) et les questions d'identité enterprise grade.
#Uber Engineering#AI agent identity#agent identity crisis
**Matt Mathew** (Sr Staff Engineer) · **Prasad Borole** (Staff Software Engineer) · **Meng Huang** (Engineering Manager) · **Sergey Burykin** (Sr Software Engineer) · **Gaurav Goel** (Software Engineer II) · **Bayard Walsh** (Software Engineer I). Tous chez **Uber** · équipe Security/Identity infrastructure responsable du déploiement de l'architecture d'identité agentique en production. Composition d'équipe représentative : un Engineering Manager · un Staff senior cadre · un Staff IC architecte · deux SWE séniors/intermédiaires · un SWE I — pattern classique d'une équipe Uber qui livre une plateforme transverse mission-critical.
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.
#X algorithm 2026#xai-org/x-algorithm#For You feed
Rapport interne **non signé** (typique des deliverables d'analyse interne / brouillon de livrable client). Sources primaires citées : (a) le repo public **`xai-org/x-algorithm`** (release 15 mai 2026) · (b) les `README.md` du repo et de ses sous-modules (`home-mixer/`, `phoenix/`, `thunder/`, `grox/`) · (c) le code source Rust (Home Mixer, Thunder) et Python/JAX (Phoenix, Grox) inspecté directement avec citations file:line. Le rapport est explicitement écrit en posture *"what we observe in the public source release · and what it implies for measurable growth interventions"* — registre de teardown analytique avec discipline d'honnêteté épistémique (section A.3 *"Honesty boundary"* listant exhaustivement ce qui n'est pas dérivable de l'OSS).
**Jessica Talisman MLS** (Semantic Engineer + Information Architect, 25+ ans expérience, ex-Adobe RDF knowledge graphs + ex-Amazon information architecture, fondatrice **Ontology Pipeline Framework** + **Contextually LLC**) publie sur **Modern Data 101** (Substack, ~20 000 membres) le **4 mai 2026** une révision majeure de son framework **Ontology Pipeline™** initialement publié en janvier 2025. **Thèse-pivot** : depuis novembre 2022 (ChatGPT), la demande de *semantic infrastructure* a explosé mais a créé une **confusion massive** — *"vendors offering shortcuts that bypass essential foundational work, creating liabilities disguised as assets"*. Le pipeline initial en **5 étapes** (controlled vocabulary → metadata standards → taxonomy → thesaurus → ontology → knowledge graph) reste valide mais **doit être complété par 2 ajouts critiques** : **(1) Governance** comme ongoing engineering practice (pas post-project documentation) ; **(2) AI Partnership** avec distinction claire augment vs replace. **Diagnostic marché** : *"a structurally invalid taxonomy is not a taxonomy"*, *"lists are not knowledge infrastructure"*, AI-generated taxonomies vendues comme stratégie, vendors abusent du terme *"ontology"*, cookie-cutter solutions présentées comme méthodologie. **Crisis pédagogique** : la demande de semantic engineers dépasse massivement l'offre de praticiens formés ; le gap est comblé par des gens *"who know vocabulary without methodology"*. **Position normative explicite** : *"AI that generates a taxonomy wholesale is producing a liability disguised as asset; AI that assists trained engineers is just plain smart."* **Rôles AI acceptables** : entity extraction, gap analysis, drafting candidate vocabularies for review, population/validation support. **Rôles AI inacceptables** : *wholesale taxonomy generation without human validation against standards*. **Standards référencés** : SKOS, OWL, RDF, SPARQL. **Crédibilité** : framework validé sur **6 institutions sur 10 ans**. **Recommandations 3 publics** : (a) Organisations — invest formal education, treat knowledge infra as AI backbone, governance ongoing, AI as accélérateur pas remplacement ; (b) Practitioners — competency questions before modeling, validate against SKOS/OWL/RDF, definitional difficulty signals pause, maintenance continue ; (c) Leaders — workforce upskilling sans self-funding education, alloc resources knowledge infra strategic necessity, governance avant deployment. **Citations percutantes** : *"the work cannot be skipped"*, *"governance is the engineering practice that keeps an ontology coherent across change"*, *"teaching this is hard. Learning it is harder."* **Pertinence majeure** pour data leaders / CDO / architects qui construisent les bases sémantiques de leurs agents IA. À articuler avec : Seale Semantic Agent (2026-04-17) — *(Model+Harness)+(Ontology+Data) — l'ontologie comme seul moat* ; Foundation Capital Context Graphs (2025-12-22) ; Bain part 2/5 *redesign data foundations for agent readiness* (2026-05) ; DORA ROI 2026 *AI-accessible internal data + healthy data ecosystems* (2026-04-21) ; Habert PROJ-AI six zones doctrine (2026-05-05). Convergence avec corpus 2026 *"data foundations as moat"*.
#Jessica Talisman MLS#Ontology Pipeline framework#Modern Data 101
**Jessica Talisman MLS** — Semantic Engineer et Information Architect avec **25+ ans d'expérience** en enterprise architecture · e-commerce systems et knowledge management. Fondatrice de l'**Ontology Pipeline Framework** et de **Contextually LLC**. Roles précédents : **Adobe** (RDF-based knowledge graphs) · **Amazon** (information architecture). Auteure de la newsletter **Intentional Arrangement** (Substack) et d'un **livre éponyme à paraître en 2026**. Le framework initial *Ontology Pipeline* a été publié en janvier 2025 et **validé sur 6 institutions sur 10 ans**.
Agent sémantique : la symétrie modèle+harnais et ontologie+données, effondrement des frameworks d'agents, ontologie comme seul actif non-commodité
#agent sémantique#harnais d'agent#ontologie
Tony Seale
Construire pour des trillions d'agents : logiciel API-first, infrastructure agentique, nouveau paradigme logiciel - X/Twitter
#agents IA#infrastructure agentique#API-first
Aaron Levie
Cloudflare — conversion HTML vers Markdown en temps réel pour agents IA via négociation de contenu HTTP
#Markdown#agents IA#négociation de contenu HTTP
Celso Martinho · Will Allen
Context Graphs Foundation Capital - nouvelle génération systèmes de record pour agents IA
#context graph#système de record#agents IA
Jaya Gupta · Ashu Garg
Jamin Ball - systèmes de record survivent aux agents IA, truth registries
#systèmes de record#agents IA#source de vérité
Jamin Ball
Acontext (memodb-io) - plateforme open-source de données contextuelles pour agents IA cloud-native - context engineering, observabilité, distillation de compétences - GitHub
#agents IA#plateforme de données contextuelles#cloud-native
memodb-io (Organization)
Construire la GenBI dans une entreprise Fortune 100 averse au risque (Northwestern Mutual) : petits paris, déploiement incrémental, agents spécialisés et démocratisation des données
#GenBI#Business Intelligence#Enterprise AI
Asaf Bord (Engineering Leader, Northwestern Mutual)
Support technique autonome livrant du code - Résolution de l'érosion applicative - Zapier ingénierie
#support technique#érosion applicative#Zapier
Lisa Orr
Bloomberg - Enterprise AI Deployment - Platform Engineering - Paved Path - Uplift Agents
#Bloomberg#AI Deployment#Platform Engineering
Lei Zhang (Head of Technology Infrastructure Engineering, Bloomberg)
Evolution RAG vers Agent Memory - Read-write operations - Gestion données inference - Vector databases - Mémoire persistante agents IA - Leonie Monigatti
#Retrieval-Augmented Generation#RAG#Agentic RAG
Leonie Monigatti
Deep Research - Révolution AI4* - 6 piliers production logicielle - Transition Copilotes→Agents - Paradoxe Vibe vs Check - Crise FinOps pour IA - Gouvernance chemin critique - GenAI Landing Zone
#AI4*#AI for Everything#AI4Project
Deep Research Veille Interne
Rippletide - Fiabilité agents IA enterprise - Gap déploiement 64% vs 17% - Decision governance manquante hyperscalers - Hypergraph Database - <1% hallucination - Compliance by design - Gartner 40% projects canceled 2027
#agent reliability#enterprise AI#decision governance
Patrick Joubert - CEO Rippletide
Format de sérialisation TOON optimisé pour LLM réduisant les coûts de jetons de 30-60% - GitHub - Johann Schopplich
#TOON#LLM#optimisation jetons
Johann Schopplich (@johannschopplich)
MCP-UI conférence détaillée, islands architecture, remote DOM, theming, état distribué, authentification, clients natifs - Monday.com
#MCP-UI#islands architecture#remote DOM
Liad Yosef (AI & MCP Lead - Monday.com, co-modérateur UI work group)
Changement de plateforme IA - Redéfinition du logiciel - Architecture AI-native - LinkedIn
#Platform Shift#AI-Native Architecture#Software Transformation
Philippe Ensarguet
Guide développement ChatGPT Apps SDK OpenAI - MCP, OAuth 2.1, Widgets
#ChatGPT Apps#OpenAI SDK#MCP
Harry (Gadget)
Déclin du RAG - Expansion des fenêtres de contexte IA - LinkedIn
#Retrieval-Augmented Generation (RAG)#AI context windows#Agentic AI
Philippe Ensarguet
CEA ExpressIF 3 - RISC-V - AI SoC - Embedded systems - Edge AI - Open source hardware - Sovereign tech
#CEA#ExpressIF 3#RISC-V
CEA (Commissariat à l'énergie atomique et aux énergies alternatives)
Construction de Claude Code - Architecture IA-first - Ingénierie produit - Pragmatic Engineer
#Claude Code#Anthropic#IA
Gergely Orosz (auteur de l'article) · Boris Cherny · Sid Bidasaria · Cat Wu (équipe fondatrice de Claude Code)
MCP remplace le navigateur - Interactions agents IA - Développeurs frontend - LogRocket Blog
#mcp#agents IA#Model Context Protocol
Peter Aideloje
Block/Goose — MCP-UI et le futur des interfaces agentiques : composants web interactifs dans les conversations d'agents IA via Model Context Protocol (block.github.io)
#Block#Goose#MCP
Block (Square) Engineering team
MCP-UI révolutionne interfaces agents IA, composants web interactifs, sandboxed iframes, accessibilité, générative UI - Goose/Block
#MCP-UI#Model Context Protocol UI#interfaces agentiques
Ebony Louis (Developer Advocate - Block/Goose)
Architecture données unifiée Netflix, knowledge graph RDF/SHACL, modélisation domaine, Upper metamodel, mappings sémantiques, projections automatiques GraphQL/Avro/Iceberg - Netflix Technology Blog
#UDA#Unified Data Architecture#knowledge graph
Alex Hutter · Alexandre Bertails · Claire Wang · Haoyuan He · Kishore Banala · Peter Royal · Shervin Afshar (Netflix Technology Blog)
LightRAG - RAG simple et rapide - Knowledge graphs - Dual-level retrieval - EMNLP2025 - GitHub
#knowledge-graph#gpt#rag
Zirui Guo · Lianghao Xia · Yanhua Yu · Tu Ao · Chao Huang (HKUDS - Hong Kong University Data Science)
NuExtract NuMind - modèle fondation extraction structurée JSON petit format
#extraction structurée#JSON#modèle de langage
Alexandre Constantin · Liam Cripwell · Etienne Bernard
Keynote **Gregor Hohpe** (Enterprise Strategist AWS, auteur *The Software Architect Elevator* et du livre en cours *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) à **PlatformCon 2022** sur **la magie des plateformes** — pourquoi les plateformes réussissent, ce qui les distingue d'une simple *IT Service Management*, et **les décisions d'architecture non-triviales** à prendre quand on en construit une. **Thèse-pivot** : *« les standards ne réduisent pas la créativité, ils peuvent la décupler »* — analogue Baltimore 1904 (incendie, pompes incompatibles), vis métrique ISO, HTTP, papier A4. **Citation canonique reprise de Peter / Thoughtworks** : ***« platforms centralize expertise but not innovation »*** — on ne réinvente pas la roue, mais on laisse l'innovation aux équipes proches du client. **Analogie pivot** : industrie automobile (Volkswagen Group construit Audi A4 et Bentley Bentayga sur la même plateforme), *« undifferentiated heavy lifting »* (vocabulaire AWS) sous le capot, différenciation visible côté client. **Trois propriétés d'une vraie plateforme** : (1) **low friction** — on ne peut pas forcer l'adoption, les équipes contourneront ; (2) **transparence** (pas une *black box*) — les utilisateurs doivent pouvoir diagnostiquer s'ils sont en cause ou si c'est la plateforme ; (3) **shared responsibility** (référence directe au *AWS Shared Responsibility Model*) — la plateforme ne corrige pas une appli mal conçue. **Anti-pattern explicite** : *« a common layer can be many things — it is not necessarily a platform »* ; l'IT Service Management traditionnelle a la même image (couche commune sous tout le monde) mais l'**interface est l'opposée** (high-friction, formulaires, bottleneck). **Deux voies de construction** : (a) anticiper tous les besoins (Hohpe : *« I don't feel I'm smart enough »*) ; (b) **évolution** à partir de pièces utiles, en observant l'usage. **Décisions à expliciter** : objectifs (cognitive load ↓, safer / fewer mistakes, faster via samples/blueprints/self-service, compliance), forme de la courbe d'apprentissage (cliff, hockey stick, gear shift). **Concept canonique #1 — Floating platforms vs Sinking platforms** : quand la *base platform* (typiquement le cloud) gagne de nouvelles capacités, **deux stratégies opposées** : **sinking platform** (statique, dupliquant ce que la base offre maintenant, coulant à mesure que le niveau monte) vs ***floating platform*** (jette les morceaux devenus redondants, **re-monte au-dessus du nouveau niveau**, innove plus haut). Métaphore *« submarine and a boat »*. Implication contractuelle forte : **prévenir explicitement les stakeholders** que des composants seront supprimés quand la base les absorbe. **Concept canonique #2 — Fruit salad vs Fruit basket** : une plateforme n'est pas une collection de capacités juxtaposées (panier) mais un assemblage **proportionné et bite-sized** où les pièces interagissent — *« the per-kilo price for fruit salad is higher than for a fruit basket »*. Le titre dérive de l'expression *the magic of platforms* — l'effet contre-intuitif où **standardiser libère l'innovation au lieu de l'étouffer**, à condition de soigner l'interface, l'évolution et l'intégration entre les composants. À mobiliser pour : architectes plateforme, **Platform Engineering / IDP teams 2026** (référence fondatrice, prédate l'explosion *Internal Developer Platforms* mais structure le vocabulaire), DSI évaluant build-vs-stagnate face aux capacités natives cloud, COMEX produit. Convergence avec **AI/works™ Thoughtworks** (2026-05-12), **L'Usine Logicielle Augmentée Wescale** (2026-05-03), **PROJ-AI Habert/WEnvision** (2026-05-05), **DORA AI ROI** (2026-04-21 — Platform comme pilier systémique).
#Plateformes logicielles#platform engineering#Internal Developer Platforms IDP
**Gregor Hohpe** — Enterprise Strategist chez Amazon Web Services · architecte logiciel · auteur prolifique (*Enterprise Integration Patterns* — référence depuis ~2003 — et *The Software Architect Elevator*, O'Reilly 2020). Au moment du talk · écrit *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse* (publié sur Leanpub, accessible via *leanpub.com/platformstrategy*). Profil : architecte *bridging the gap between business and tech* · expérience CTO Allianz · conseil C-suite · conférencier régulier (QCon, GOTO, PlatformCon). Référence majeure dans l'architecture d'entreprise et l'intégration. Talk donné en **keynote PlatformCon 2022** (juin 2022, conférence en ligne organisée par platformengineering.org).