thekb.eu — Architecture & Construction

Un SDLC piloté par l'IA : le cycle SFEIR à 11 phases (et pourquoi l'industrie y converge)

Tue, 16 Jun 2026 00:00:00 GMT

Cet article de SFEIR formalise un cycle de développement logiciel piloté par l'IA en **onze phases (0 à 10)** et argumente que l'industrie converge vers ce type de modèle. Le point de départ est un diagnostic : en 2025, les organisations ont déployé des outils d'IA sans transformer leur modèle opératoire, produisant un paradoxe résumé par la formule « tout change… et rien ne change » — la vitesse d'exécution se multiplie sans gain proportionné. Le vrai défi n'est donc pas de choisir les bons outils, mais de **repenser le cycle de vie logiciel** lui-même pour une exécution menée par la machine. Le cycle SFEIR enchaîne : **0 Setup** (détection de stack, mémoire projet), **1 Define** (spécification — porte humaine), **2 Plan** (arbitrage d'architecture — porte humaine), **3 Build** (développement par l'agent), **4 Verify** (tests automatisés et couverture), **5 Review** (quatre audits parallèles : code, sécurité, tests, performance), **6 Compound-1** (capture des leçons avant déploiement), **7 Ship** (acceptation en production — porte humaine), **8 Ops** (monitoring et rollback), **9 Compound-2** (leçons issues du runtime) et **10 Deprecation** (retrait et capitalisation). Trois **portes humaines inamovibles** — Define, Plan, Ship — encadrent un ensemble de phases sinon automatiques ; deux **moments de capitalisation** (Compound-1 et Compound-2) transforment les leçons en règles réutilisables qui nourrissent les cycles suivants. Trois principes structurent l'approche. D'abord, **l'IA exécute, elle n'assiste pas** : les agents produisent des artefacts complets (code, tests, documentation) sur des phases entières, et une discipline de **preuve d'exécution** capte les sorties réelles — le système ne fait jamais confiance aux déclarations de l'agent. Ensuite, **l'humain garde le contrôle de l'intention** via les trois gates : il décide quoi construire, la machine optimise l'exécution. Enfin, **le système apprend cumulativement**, chaque cycle enrichissant le suivant. Les résultats avancés étayent la thèse : une refonte de site passée de six mois à un jour, **−30 % d'itérations de correction après dix cycles** (un bug signalé deux fois devient une règle automatisée), des revues sur quatre angles parallèles, un coût d'augmentation d'environ 10 €/heure, et un objectif de 850 consultants entièrement augmentés fin 2026. L'article revendique une **convergence industrielle** avec l'ADLC (deux gates, « l'intention vérifiée exactement deux fois »), le whitepaper Google sur le nouveau SDLC (41 % de code IA, 85 % de devs sur agents) et DORA 2025 (l'IA « amplificateur »). Il délimite enfin les usages adaptés (back-offices, API, migrations, sorties vérifiables) et inadaptés (design novateur, safety-critical sans normes, données non gouvernées), et recommande de commencer par une porte de spécification rigoureuse et la preuve d'exécution. Premier volet d'une série de sept.

The End of Code Review: Coding Agents Supersede Human Inspection

Thu, 11 Jun 2026 00:00:00 GMT

Dans ce position paper publié sur arXiv (catégorie génie logiciel), Martin Monperrus défend une thèse qui heurte frontalement une pratique fondatrice du SDLC : les agents de codage ont atteint un niveau de capacité tel que **la revue de code humaine n'est plus un composant nécessaire d'un pipeline qualité**. L'argument repose sur deux affirmations. D'abord, une **parité — voire une supériorité — de capacité** : des systèmes autonomes fondés sur des LLM remplissent tous les objectifs traditionnels de la revue (trouver les défauts, améliorer la qualité, assurer la conformité, partager la connaissance) à un coût moindre et avec un débit supérieur, sans la fatigue ni l'inconstance humaines. Ensuite, un **problème d'échelle** : le modèle hybride dominant — l'agent écrit le code, l'humain le relit — ne fournit ni assurance qualité réelle ni capacité à suivre la vélocité de la production assistée par IA ; il engendre surtout une **fausse sécurité**. Monperrus situe sa cible historiquement, en visant l'inspection de Fagan (1976), et s'appuie sur les travaux de Bacchelli & Bird montrant que la revue attrape en pratique moins de bugs que les développeurs ne l'imaginent. Les benchmarks (SWE-bench, ~20-40 % d'issues résolues selon les modèles, avec des courbes de progression rapides) servent de preuve de capacité. À la place de la revue humaine, il propose un **pipeline de vérification adversariale multi-agents** : un agent génère le code ; un ou plusieurs agents reviewers indépendants l'inspectent (défauts, sécurité, style) ; une couche de vérification ajoute tests automatisés et méthodes formelles ; un mécanisme de consensus fait voter plusieurs agents pour accepter ou rejeter. Le goulot d'un relecteur humain unique est remplacé par une inspection distribuée et infatigable. L'humain ne disparaît pas : il se recentre sur la spécification et les exigences de haut niveau, les arbitrages d'architecture, la supervision des domaines critiques, les cas limites, et reste la porte d'approbation finale des systèmes sensibles. L'auteur traite explicitement les objections — hallucinations et injection de prompt, limites du test automatisé (d'où le property-based testing), perte d'expertise de domaine (compensée par fine-tuning et RAG) — sans les esquiver. Côté SDLC, il relie la revue aux métriques DORA : accélérer le débit de revue accélère le déploiement. Ses recommandations sont pragmatiques : piloter d'abord sur des composants à faible risque, garder un workflow hybride initial (agents signalent, humains approuvent), mesurer les taux de détection agent contre humain, expliciter les décisions de rejet, et créer des boucles de feedback. Un texte volontairement provocateur, mais une contre-thèse précieuse au dogme du « gate de revue humain inviolable ».

The pattern lineage: Why fifty years of design patterns may hold the key to growing the architects AI cannot replace

Wed, 10 Jun 2026 00:00:00 GMT

Philippe Ensarguet (Orange) part d'une question en apparence administrative — concevoir un parcours de montée en compétences vers le rôle d'architecte — pour formuler une intuition de fond. Ce rôle est critique pour la « platformisation » d'un opérateur télécom (réunir les mondes IT et réseau, séparés depuis des décennies, en plateformes programmables). Or il devient critique au moment précis où son pipeline de formation se brise : la demande d'architectes augmente (platforming, cloud-native, IA agentique déplacent la complexité des composants vers les relations entre eux), tandis que la chaîne d'approvisionnement en talents se démantèle. Le chemin traditionnel passait par des années d'écriture de code ; l'IA en absorbe désormais une part croissante. Si le travail d'entrée de gamme qui forgeait les architectes est délégué aux machines, d'où viendra la prochaine génération ? La réponse, selon Ensarguet, est sur les étagères depuis cinquante ans. Il revient au sens originel d'un pattern, défini par l'architecte-bâtisseur Christopher Alexander (1977) : une solution nommée et récurrente à un problème dans un contexte, incluant les forces en tension et les conséquences. Ce n'est pas une recette, c'est du jugement transmissible. Le livre du Gang of Four (1994), issu du Hillside Group réuni par Kent Beck et Grady Booch, a donné à l'industrie son premier vocabulaire partagé — sa valeur durable étant le format (problème, contexte, forces, solution, conséquences), pas les 23 patterns. Ensarguet déroule un arbre généalogique : POSA (1996), Fowler (2002), Hohpe & Woolf (2003), Nygard (2007, Circuit Breaker), les catalogues cloud (2012+), microservices et Kubernetes (2018-2019), jusqu'aux corpus agentiques en train de se former (Anthropic « Building Effective Agents », les quatre patterns d'Andrew Ng, le cadre à deux axes de Huang & Zhou en 2026 — écho des deux axes du GoF trente ans plus tôt). Sous les catalogues subsistent six forces invariantes : couplage/cohésion, frontière d'abstraction, isolation des pannes, gouvernance de l'état, indirection, boucle de rétroaction — auxquelles s'ajoute une septième, le non-déterminisme introduit par les systèmes agentiques. Cette « pattern literacy » est la compétence résiliente, et la seule à enfin relier IT et réseau (control plane/user plane = indirection ; network slicing = Bulkhead ; intent-based networking = boucle de rétroaction). L'IA devient alors alliée : libérée de l'implémentation, la formation peut être délibérée — la machine produit des options, l'humain fournit le jugement. Il faut enseigner la grammaire, pas les catalogues : les catalogues vieillissent, la façon de penser qu'ils encodent, non. Ensarguet publie cette thèse pour la mettre à l'épreuve du débat.

How AI Changes the SDLC: A Six-Stage Guide

Mon, 08 Jun 2026 00:00:00 GMT

Ce guide d'Augment Code, signé Paula Hingel, propose un modèle en **six étapes** pour comprendre comment les agents IA restructurent le cycle de vie logiciel. Sa thèse centrale : l'IA n'améliore pas uniformément le SDLC — elle augmente le débit sur certaines étapes tout en accroissant le risque d'instabilité sur d'autres. Ce déséquilibre n'est pas une fatalité technologique mais le symptôme d'une adoption inégale menée **sans redessiner les frontières de revue**. L'article s'appuie sur le **rapport DORA 2025**, qui établit une corrélation positive entre adoption de l'IA et débit/performance produit, mais **négative avec la stabilité de livraison** : la maturité du process compte davantage que l'outil. Les six étapes sont relues à cette aune. (1) **Requirements & Planning** : la spécification devient le mécanisme de contrôle qui dirige l'agent ; l'humain se concentre sur la qualité du besoin et la levée d'ambiguïté. (2) **Design & Architecture** : davantage de décisions exigent une revue humaine explicite, pour éviter le « vibe architecting » — des choix d'infrastructure ou d'intégration faits en secondes, plus vite que la gouvernance ne peut les encadrer. (3) **Implementation** : le développeur glisse de l'écriture de code vers l'orchestration, la validation et l'approbation. (4) **Testing & QA** : le risque cœur est la **validation circulaire**, où des tests générés par l'IA confirment du code généré par l'IA au lieu de vérifier le besoin réel ; la spécification précise est le rempart. (5) **Deployment** : les gains de débit créent des risques de stabilité, d'où la nécessité de contrôles de rollback renforcés. (6) **Maintenance & Operations** : les agents prennent en charge détection et remédiation, l'humain gère exceptions et durcissement. Trois risques structurels sont nommés : l'**érosion du pipeline junior** (automatiser les tâches fondatrices plus vite qu'on ne redessine les rôles juniors rétrécit le futur vivier de seniors), la validation circulaire, et les lacunes de gouvernance à l'échelle. En miroir, trois rôles émergent : **Intent Engineering** (traduire des objectifs ambigus en specs testables), Agentic DevOps/Infra (orchestrer les agents) et AI Governance/Assurance. Le guide est étayé de données : 70 % du temps dev passé à comprendre du code existant, une étude CMU (807 dépôts) montrant +30 % d'issues statiques et +40 % de complexité, ou le système DRS de Meta (>10 000 changements landés pendant un code freeze). Il se clôt sur cinq recommandations opérationnelles : auditer une étape avant de scaler, stress-tester la gouvernance, rendre la spécification centrale, définir des politiques de rollback explicites, et redessiner le rôle des juniors autour de la revue.

Solving the Identity Crisis for AI Agents

Thu, 21 May 2026 00:00:00 GMT

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.

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.

The Ontology Pipeline™, Refresh: Where We Were, Where We Are, and Where We're Headed

Mon, 04 May 2026 00:00:00 GMT

**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"*.

There is a growing disconnect in the way people think about building AI agents

Fri, 17 Apr 2026 00:00:00 GMT

Tony Seale, The Knowledge Graph Guy, identifie une déconnexion croissante dans la façon dont l'industrie construit les agents IA. D'un côté, l'industrie investit massivement dans des frameworks d'orchestration : LangGraph, CrewAI, AutoGen, Semantic Kernel, OpenAI Agents SDK, AWS Bedrock, Google ADK — chacun avec ses graphes d'orchestration, machines à états et logiques de routage. De l'autre, les praticiens de pointe sont passés au paradigme « modèle puissant dans harnais puissant » (Claude Code, Codex, OpenClaw, Hermes). **L'effondrement des frameworks.** Les early frameworks étaient nécessaires quand les modèles ne géraient pas le multi-étape seuls. Citation d'Anthropic : « tout composant d'un harnais encode une hypothèse sur ce que le modèle ne peut pas faire seul, et ces hypothèses vieillissent vite ». Le scaffolding construit pour un modèle limité handicape un modèle intelligent. Il doit diminuer avec le temps, pas s'accumuler. Ce qui reste est simple : un modèle puissant dans un harnais puissant. Beaucoup, interagissant, collaborant. Pas de framework requis. **Les agents isolés ne suffisent pas.** Accès à l'ordinateur ≠ compréhension. Donnez à un agent 1000 documents : il cherche, espère, devine. Multipliez par 50 agents sans modèle du monde partagé et vous obtenez une intelligence d'isolation mais incohérente en combinaison. À l'échelle entreprise, l'environnement d'information a besoin de structure — un modèle de domaine partagé, avec l'humain dans la boucle. **La symétrie.** La réponse est d'appliquer la même simplification côté données. Le modèle siège dans un harnais qui lui donne accès à l'ordinateur ; les données siègent dans une ontologie qui leur donne structure et sens. L'ontologie définit ce qui existe, ses propriétés, ses relations — l'interface via laquelle les agents comprennent la donnée. Deux patterns symétriques : (modèle puissant + harnais puissant) et (données puissantes + ontologie puissante). **Le Semantic Agent.** Leur combinaison donne le Semantic Agent : (Model + Harness) + (Ontology + Data). Il ne se contente pas de générer, il commence à comprendre. Tout le reste est scaffolding — utile un temps, mais appelé à tomber. **Ce que vous possédez.** Tout le monde a accès aux mêmes modèles frontier ; tout le monde peut construire un harnais. C'est commodité, et cela se « thinne out » chaque jour. Ce qui n'est PAS commodité : votre ontologie, votre modèle de domaine, la connaissance structurée et liée qui capture comment votre organisation comprend le monde. Les frameworks sont une phase transitoire. Les modèles sont loués. La seule chose qu'il reste à construire — et qui vous appartient — est la connaissance.

Building for trillions of agents

Sat, 07 Mar 2026 00:00:00 GMT

Aaron Levie, CEO de Box, publie un essai strategique sur la transformation fondamentale du logiciel dans un monde ou les agents IA deviennent les principaux utilisateurs de toute application. Il observe que depuis fin 2025, les agents ont franchi un cap decisif : ils disposent de leur propre environnement compute sandboxe, peuvent ecrire et executer du code, interagir avec des API et CLI, gerer leurs propres fichiers et memoire a long terme. Cette architecture, initialement definie par les agents de codage (Claude Code, Devin, Codex, Cursor, Replit), s'est etendue a tout le travail intellectuel avec des agents comme Claude Cowork, Perplexity Computer, Manus et OpenClaw, ce dernier fonctionnant 24/7 dans un environnement persistant. Levie predit que chaque employe disposera de nombreux agents, avec 100 a 1000 fois plus d'agents que de personnes dans une entreprise, soit des trillions d'agents a l'echelle mondiale. Adaptant le celebre conseil de Paul Graham ("Make something people want"), Levie propose un nouveau paradigme : "Make something agents want". Les agents choisiront eux-memes les outils les plus adaptes, sans etre influences par le marketing traditionnel. La consequence majeure : tout doit devenir API-first. Sans API, une fonctionnalite n'existe pas pour les agents. CLI et serveurs MCP deviennent indispensables. Levie cite Jared Friedman de YC qui avertit que les outils ne permettant pas l'inscription via API sont "morts pour les agents". Les modeles economiques doivent aussi evoluer : le modele par siege ne suffit plus quand un agent peut realiser des heures de travail humain en quelques lignes de texte. Il faudra des modeles bases sur la consommation et le volume, voire permettre aux agents de gerer leurs propres paiements. Levie decrit ensuite l'ecosysteme d'infrastructure necessaire : environnements sandbox (E2B, Daytona, Modal, Cloudflare), gestion de fichiers (Box), identite et email pour agents (Agentmail), recherche web (Parallel, Exa), paiements (Stripe, Coinbase), et potentiellement des microtransactions. La securite, la conformite et la gouvernance deviennent des enjeux majeurs quand les agents manipulent des donnees sensibles dans des workflows regules (pharma, banque). Les agents auront besoin de leurs propres identites avec des controles stricts sur leurs actions et acces aux donnees. En conclusion, Levie affirme que nous entrons dans une nouvelle ere du logiciel ou les outils doivent etre concus specifiquement pour des agents operant a une echelle sans precedent.

Introducing Markdown for Agents

Thu, 12 Feb 2026 00:00:00 GMT

Cloudflare annonce une nouvelle fonctionnalité permettant de convertir automatiquement le contenu HTML en Markdown en temps réel, spécifiquement conçue pour les agents IA. Le constat de départ est simple : le HTML est extrêmement inefficace pour la consommation par les modèles de langage. Un simple titre qui nécessite 3 tokens en Markdown en consomme 12 à 15 en HTML. À l'échelle d'une page web complète, la conversion permet une réduction de 80 % du nombre de tokens utilisés, avec des gains directs en coût et en latence. Le mécanisme repose sur la négociation de contenu HTTP, un standard existant du web. Lorsqu'un agent IA envoie une requête avec le header `Accept: text/markdown`, le réseau edge de Cloudflare intercepte la réponse HTML du serveur d'origine et la convertit à la volée en Markdown avant de la renvoyer à l'agent. Cette approche est particulièrement élégante car elle ne nécessite aucune modification côté serveur d'origine : tout se passe sur l'infrastructure Cloudflare. L'article présente également le framework Content Signals, qui permet aux éditeurs de sites web d'exprimer leurs préférences quant à l'utilisation de leur contenu. Trois signaux sont définis : `ai-train` (autorisation d'entraînement), `search` (indexation pour la recherche) et `ai-input` (utilisation comme entrée par les agents IA). Ce mécanisme donne aux éditeurs un contrôle granulaire sur la manière dont les agents interagissent avec leur contenu. Les auteurs soulignent que des agents de codage populaires comme Claude Code envoient déjà le header `Accept: text/markdown`, ce qui témoigne d'une adoption organique de cette approche. Pour les cas d'usage plus complexes, Cloudflare propose des alternatives complémentaires : Workers AI avec la méthode `AI.toMarkdown()` pour une conversion programmatique, et la Browser Rendering API pour les pages nécessitant un rendu JavaScript. Cloudflare Radar permet de suivre les patterns d'utilisation du markdown par les différents crawlers IA, offrant une visibilité précieuse sur l'évolution de cet écosystème. Par ailleurs, Cloudflare lance un Toolshed regroupant plus de 400 outils MCP (Model Context Protocol), se positionnant comme une plateforme centrale pour l'outillage des agents IA. La fonctionnalité est disponible en version bêta pour les abonnés aux plans Pro, Business et Enterprise. Cette initiative s'inscrit dans une tendance plus large où l'infrastructure web s'adapte pour servir non plus seulement les navigateurs humains, mais aussi les agents IA autonomes qui deviennent des consommateurs majeurs de contenu web.

AI's trillion-dollar opportunity: Context graphs

Mon, 22 Dec 2025 00:00:00 GMT

Jaya Gupta et Ashu Garg de Foundation Capital développent une thèse sur l'émergence d'une nouvelle génération de systèmes de record centrés sur les traces de décision plutôt que sur les objets métier traditionnels. La génération précédente de logiciels enterprise a créé un écosystème trillion-dollar en devenant des systèmes de record : Salesforce pour les clients, Workday pour les employés, SAP pour les opérations. La question actuelle est de savoir si ces systèmes survivront au passage aux agents IA. Les auteurs s'accordent avec l'analyse de Jamin Ball selon laquelle les agents ne remplacent pas les systèmes de record mais en élèvent les exigences. Cependant, ils identifient une couche manquante critique : les traces de décision. Ces dernières capturent les exceptions, dérogations, précédents et contexte cross-système qui vivent actuellement dans Slack, les conversations de deal desk, les appels d'escalade et la mémoire des employés. La distinction fondamentale oppose les règles (ce qui devrait se passer en général) aux traces de décision (ce qui s'est passé dans ce cas spécifique, sous quelle politique, avec quelle exception, sur quel précédent). Les agents ont besoin d'accéder non seulement aux règles mais à l'historique de leur application. Les startups "systems of agents" disposent d'un avantage structurel : elles se situent dans le chemin d'exécution. Elles voient le contexte complet au moment de la décision et peuvent persister ces traces comme des artefacts durables. L'accumulation de ces traces forme un "context graph" : un enregistrement vivant des décisions reliées entre entités et dans le temps, où le précédent devient requêtable. Les incumbents ne peuvent pas construire ce context graph. Les systèmes opérationnels comme Salesforce stockent l'état actuel, pas l'état au moment de la décision. Les data warehouses comme Snowflake reçoivent les données via ETL après que les décisions sont prises, perdant le contexte décisionnel. Les auteurs identifient trois chemins pour les startups : remplacer des systèmes de record existants (comme Regie pour les plateformes de sales engagement), remplacer des modules spécifiques (comme Maximor pour la finance), ou créer de nouveaux systèmes de record pour des catégories de vérité jamais capturées (comme PlayerZero pour le production engineering). Les signaux pour identifier ces opportunités incluent un headcount élevé sur des workflows manuels, des décisions riches en exceptions, et l'existence d'organisations "glue" (RevOps, DevOps, SecOps) qui existent précisément parce qu'aucun système ne capture le workflow cross-fonctionnel.

Clouded Judgement 12.12.25 - Long Live Systems of Record

Fri, 12 Dec 2025 00:00:00 GMT

Jamin Ball publie une analyse contrariante face au narratif dominant selon lequel les agents IA rendraient obsolètes les systèmes de record traditionnels. Sa thèse centrale : les agents ne remplacent pas ces systèmes, ils élèvent les exigences de ce qu'un bon système de record doit offrir. L'auteur commence par critiquer les déclarations récurrentes affirmant que "les agents sont le nouveau système de record" ou que "les workflows avalent les systèmes de record". Bien qu'il reconnaisse une part de vérité dans ces affirmations, il met en garde contre une surévaluation qui pourrait conduire les entreprises à éliminer ce dont elles ont le plus besoin : une source fiable de vérité. Ball illustre le problème fondamental avec l'exemple du calcul de l'ARR (Annual Recurring Revenue). Dans une entreprise typique, les équipes sales, finance, comptabilité et juridique peuvent utiliser des définitions différentes et des sources de données conflictuelles pour ce même indicateur. Cette ambiguïté, gérable quand des humains interviennent, devient critique quand des agents automatisent des décisions. Le point de fragilité des workflows pilotés par agents réside dans leur capacité à extraire la bonne valeur du bon système au bon moment. Si une étape précoce d'un workflow quote-to-cash récupère la mauvaise liste de prix, le mauvais terme contractuel ou un chiffre d'ARR obsolète, tout le reste du processus automatisera avec confiance la mauvaise chose. Ball propose une vision évolutive où les data warehouses et lakehouses deviennent des "truth registries" - des registres de vérité fournissant les couches sémantiques et frameworks de gouvernance dont les agents ont besoin pour opérer en sécurité. Dans cette architecture, les interfaces SaaS traditionnelles perdent en importance tandis que l'infrastructure data sous-jacente devient critique. L'auteur insiste sur une distinction fondamentale : un système de record n'est pas une catégorie de produit mais une source canonique de vérité. Cette nuance change la perspective sur ce que doivent construire les entreprises à l'ère des agents. L'article inclut également des données de marché SaaS montrant une médiane de multiples de revenus NTM à 4.9x, avec les entreprises à forte croissance commandant 14.5x contre 3.7x pour celles à croissance lente. Cette analyse a été explicitement référencée par Foundation Capital dans leur thèse sur les context graphs comme le point de départ de leur réflexion sur l'évolution des systèmes de record.

Acontext: Context Data Platform for Cloud-Native AI Agents

Thu, 11 Dec 2025 00:00:00 GMT

Acontext est une plateforme de données contextuelles open-source développée par l'organisation memodb-io, conçue pour construire des agents IA cloud-native. Le projet fournit une infrastructure complète couvrant le stockage du contexte, l'ingénierie contextuelle, l'observabilité des agents et l'auto-apprentissage par distillation de compétences à partir des tâches complétées. L'architecture est pensée pour les environnements cloud-native : infrastructure scalable et distribuée, support multi-langage (Python et JavaScript/TypeScript), API REST et SDK, architecture modulaire et extensible, intégration avec les principaux frameworks d'agents et support des workflows CI/CD. Cinq fonctionnalités structurent la plateforme. Le stockage de contexte conserve les contextes et artefacts produits par les agents. L'ingénierie contextuelle automatise la préparation et l'optimisation des contextes injectés aux agents. L'observabilité assure le suivi des tâches des agents et la collecte du feedback utilisateur. L'auto-apprentissage distille des compétences réutilisables à partir des tâches complétées, permettant une amélioration continue des performances. Enfin, un dashboard unifié offre une visualisation complète de toutes les activités. Côté adoption, le projet affichait au 11 décembre 2025 environ 1 721 étoiles GitHub et 137 forks, avec une communauté active sur Discord, des packages publiés sur PyPI et npm, et une documentation multilingue (8 langues supportées). Les cas d'usage visés incluent le développement d'agents autonomes dotés d'une mémoire contextuelle, l'amélioration continue des performances via l'apprentissage, la centralisation des données contextuelles pour les systèmes multi-agents, et l'analyse et l'optimisation des workflows agentiques. Les forces du projet tiennent à son approche complète (stockage + context engineering + apprentissage dans une même plateforme), à son caractère open-source avec communauté active, à sa conception cloud-native et à sa documentation riche. Les opportunités sont significatives : Acontext pourrait devenir un standard de gestion de contexte des agents, s'intégrer plus largement dans l'écosystème IA, viser le marché entreprise avec un support professionnel, et servir de plateforme de recherche sur l'apprentissage des agents. Les défis restent réels : courbe d'apprentissage pour les nouveaux utilisateurs, concurrence sur un marché émergent où plusieurs solutions se positionnent, gestion de la performance à grande échelle, et protection des données sensibles contenues dans les contextes. Acontext comble un vide important dans l'infrastructure des agents IA en fournissant des capacités d'ingénierie contextuelle et d'auto-apprentissage essentielles aux agents autonomes. Le projet mérite l'attention des équipes travaillant sur des systèmes agentiques complexes nécessitant une gestion avancée du contexte et un apprentissage continu.

Small Bets, Big Impact: Building GenBI at a Fortune 100 (Northwestern Mutual)

Sun, 23 Nov 2025 00:00:00 GMT

Asaf Bord, Engineering Leader chez Northwestern Mutual (une entreprise de services financiers de 160 ans), partage son expérience de construction d'un système de **GenBI** (Generative Business Intelligence) dans un environnement extrêmement averse au risque. La devise de l'entreprise, "responsabilité générationnelle", impose une stabilité absolue, rendant l'innovation IA difficile à vendre et à déployer. Pour réussir, Bord a adopté une stratégie de **"petits paris" (incremental rollout)** et une approche "Crawl, Walk, Run". Au lieu de promettre un agent omniscient immédiatement, ils ont commencé par cibler les experts BI eux-mêmes, puis les managers, utilisant l'IA pour accélérer leur travail plutôt que de les remplacer. L'architecture technique reflète cette prudence. Plutôt que de laisser l'IA générer du SQL complexe sur toute la base de données (risqué), ils ont construit un pipeline d'agents spécialisés : 1. **Metadata Agent** : Comprend le contexte de la question. 2. **RAG Agent** : Cherche d'abord si un **rapport certifié existant** contient la réponse. Ils ont découvert que 80% des demandes BI consistaient simplement à trouver le bon rapport. Automatiser cela apporte une valeur immense avec un risque minime. 3. **SQL Agent** : Intervient uniquement si aucun rapport n'existe, pour générer des requêtes ciblées. 4. **BI Agent** : Formule la réponse finale. Un point clé de leur succès a été l'utilisation de **données réelles et "sales"** dès le début, impliquant les utilisateurs métier dans le processus de recherche. Cela a permis de valider la faisabilité réelle et de créer des alliés ("champions") dans l'entreprise. De plus, le projet a été découpé en sprints de 6 semaines, chaque étape livrant une valeur autonome (ex: l'amélioration des métadonnées pour l'IA a servi à toute l'entreprise), permettant au management de garder le contrôle sur l'investissement. Bord conclut sur une réflexion économique : l'IA remet en cause le modèle de facturation "par siège" (seat-based) des logiciels SaaS, car un seul utilisateur peut désormais produire la valeur de dix.

Empowering Support to Ship Code: Solving App Erosion

Sun, 23 Nov 2025 00:00:00 GMT

Lisa Orr, leader ingénierie chez Zapier, présente comment l'entreprise combat "l'érosion applicative" en autonomisant les équipes support pour livrer du code. Utilisant l'analogie du Grand Canyon - où l'érosion naturelle crée de la beauté sur des millions d'années - elle contraste avec l'érosion applicative qui dégrade continuellement les 8000+ intégrations de Zapier depuis 14 ans. Le problème est critique : les APIs tierces changent constamment, créant une **crise du backlog** où les tickets arrivent plus vite qu'ils ne sont résolus. Cela génère des problèmes de fiabilité, une mauvaise expérience client, et potentiellement du churn. Face à cette réalité, Zapier lance deux expériences parallèles il y a deux ans. **Experiment 1** transforme le rôle du support : de simple triage vers la correction active de bugs. L'approche est prudente avec des garde-fous : focus sur 4 apps cibles, revue obligatoire par l'ingénierie, limitation aux corrections d'apps. La motivation est forte car l'érosion représente une source majeure de bugs, le support est avide d'apprendre (beaucoup veulent devenir ingénieurs), et certains membres aidaient déjà officieusement. **Experiment 2 - Scout** utilise l'IA générative pour accélérer les corrections. Le processus commence par du "dog fooding" (Orr elle-même corrige des apps), l'observation des ingénieurs et du support, et l'identification des pain points. Découverte clé : **50% du temps est passé à rassembler le contexte** nécessaire pour comprendre le problème. L'architecture de Scout comprend trois composants principaux : 1. **Context Analyzer** : Rassemble automatiquement tickets, logs d'erreurs, documentation API, code source 2. **Diff Generator** : Crée les corrections basées sur le contexte analysé 3. **Test Generator** : Génère des tests pour valider les corrections Les résultats sont remarquables. Le **taux de succès des merge requests atteint 97%**, avec seulement 3% nécessitant des modifications mineures. Le temps de résolution passe de **72 heures à quelques minutes**. L'impact culturel est profond : le support se sent valorisé, l'ingénierie est libérée pour l'innovation, et la frontière entre les rôles s'estompe. Orr souligne que cette transformation n'est pas qu'une optimisation technique mais une nécessité stratégique. Dans un écosystème où les intégrations sont centrales et l'érosion inévitable, la capacité de maintenance agile devient un avantage concurrentiel. L'autonomisation du support via l'IA représente une évolution organisationnelle fondamentale pour survivre dans un monde d'APIs en perpétuelle mutation.

What We Learned Deploying AI within Bloomberg’s Engineering Organization

Sun, 23 Nov 2025 00:00:00 GMT

Lei Zhang, responsable de l'infrastructure technologique chez Bloomberg, détaille comment une organisation de 9 000 ingénieurs déploie l'IA de manière structurée et efficace. Avec une base de code massive et critique (marchés financiers), Bloomberg ne peut pas se permettre une adoption chaotique. Zhang distingue l'IA pour le "coding" (écriture de nouvelles fonctionnalités) de l'IA pour le **"Software Engineering"** (maintenance, opération). Bloomberg met l'accent sur ce deuxième aspect, souvent négligé mais à fort ROI : 1. **Uplift Agents** : Des agents dédiés aux migrations et aux correctifs de sécurité de masse, capables de proposer des patchs expliqués sur l'ensemble de la codebase. 2. **Incident Response Agents** : En cas de panne, l'IA est utilisée pour scanner instantanément logs, télémétrie et configurations. Sa force est d'être "rapide et sans biais" (contrairement aux humains qui ont des préjugés sur la cause probable). Pour gérer cette échelle, Bloomberg applique le principe du **"Paved Path" (la voie pavée)** : rendre la bonne méthode facile et la mauvaise difficile. Ils ont construit une plateforme centralisée offrant une passerelle IA (Gateway), un déploiement PaaS simplifié pour les outils internes, et surtout un **Hub MCP** (Model Context Protocol) pour partager les connecteurs et éviter que chaque équipe ne recrée les mêmes outils. Sur le plan humain, Zhang note que l'adoption est plus forte chez les contributeurs individuels que chez les managers. Pour pallier cela, Bloomberg a intégré l'IA dans le cursus de formation des nouveaux arrivants. Ces "juniors" deviennent alors des vecteurs de changement, challengeant les seniors avec de nouvelles méthodes. Zhang conclut en soulignant que l'IA change la **"fonction de coût"** de l'ingénierie : certaines tâches autrefois coûteuses (migrations, docs) deviennent bon marché, invitant à repenser les compromis habituels du développement logiciel.

The Evolution from RAG to Agentic RAG to Agent Memory

Mon, 03 Nov 2025 00:00:00 GMT

Leonie Monigatti présente dans cet article technique l'évolution architecturale depuis le RAG vanilla (2020) vers l'Agent Memory, traçant la progression de la manière dont les systèmes IA accèdent aux connaissances externes et les gèrent, avec un focus sur le flux bidirectionnel d'information entrant et sortant des fenêtres de contexte des LLM. **RAG vanilla (2020) : la couche fondation** Le Retrieval-Augmented Generation a introduit la récupération en un coup depuis des sources de connaissances externes. Architecture simple : stockage hors ligne + une seule récupération par requête. Question centrale : "Comment récupérer ?" La recherche sémantique via bases de données vectorielles permet d'augmenter le LLM avec de l'information externe pertinente. Limite : récupération déterministe, en une seule passe, sans raffinement adaptatif de la requête. **Agentic RAG : capacité de récupération dynamique** L'évolution introduit les appels d'outils permettant à l'agent de déterminer si une information supplémentaire est nécessaire. Le pseudo-code illustre la transition : ``` SearchTool disponible → L'agent évalue la pertinence → Plusieurs tours de récupération possibles ``` La question se déplace : "Comment récupérer ?" devient "Dois-je récupérer ?" L'agent décide de manière autonome quand et où récupérer l'information. La récupération devient plus stratégique, contextuelle et itérative. Mais les opérations restent en lecture seule : l'information ne circule que vers la fenêtre de contexte. **Agent Memory : gestion complète des données** "L'étape logique suivante après l'évolution du RAG vanilla vers l'Agentic RAG." Introduit un WriteTool aux côtés du SearchTool. Changement de paradigme majeur : opérations de lecture-écriture. La question devient : "Comment l'information est-elle gérée ?" Le pseudo-code montre la transformation : ``` SearchTool (lecture) + WriteTool (écriture) → Flux d'information bidirectionnel → Apprentissage persistant ``` L'information circule dans les deux sens : non seulement récupérer, mais aussi stocker et modifier pendant l'inférence. Les capacités d'apprentissage persistant des agents en sont fondamentalement modifiées. **Applications pratiques démontrées** **Expériences utilisateur personnalisées** : le stockage de l'historique de conversation assure la continuité entre sessions. Préférences utilisateur et patterns d'interaction sont persistés. **Création automatique de souvenirs** : le système extrait et stocke les détails importants (préférences, dates, noms) sans commande explicite de l'utilisateur. Gestion proactive de la mémoire. **Systèmes de mémoire multi-sources** : architecture supportant des types de mémoire distincts : - **Mémoire procédurale** : workflows, savoir-faire - **Mémoire épisodique** : interactions passées, historique de contexte - **Mémoire sémantique** : faits, connaissances du domaine La séparation permet des stratégies de récupération spécialisées par type de mémoire. **Nouveaux défis introduits** L'article, équilibré, souligne les défis : **Corruption de mémoire** : les opérations d'écriture peuvent introduire des erreurs et des informations obsolètes. Des stratégies de validation sont nécessaires. **Complexité de gestion** : versionnage, résolution de conflits et politiques de rétention deviennent nécessaires. Plus de puissance = gouvernance plus complexe. **Confidentialité** : le stockage persistant soulève des questions de rétention des données, de consentement et de droit à l'oubli. **Changement de paradigme résumé** L'évolution représente un basculement fondamental des systèmes centrés sur la récupération vers la gestion complète des données. Le RAG récupérait la connaissance, l'Agentic RAG décidait quand récupérer, l'Agent Memory gère intégralement le cycle de vie de la connaissance. Citation clé : "Agent memory represents paradigm shift from retrieval-focused systems to comprehensive data management." Progression du framework : augmentation statique → récupération dynamique → apprentissage persistant. Chaque étape s'appuie sur les capacités précédentes en ajoutant une couche d'autonomie. L'Agent Memory permet aux agents d'apprendre des interactions, de construire des bases de connaissances et de personnaliser les réponses selon l'expérience accumulée. La transformation d'un outil de récupération en plateforme de gestion de données redéfinit fondamentalement l'architecture des agents LLM.

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).

Agent reliability: What's missing in Enterprise AI agent architecture?

Wed, 29 Oct 2025 00:00:00 GMT

Patrick Joubert, CEO de Rippletide, identifie un écart critique dans le déploiement des agents IA en entreprise : 64% des dirigeants technologiques veulent déployer de l'IA agentique dans les 24 prochains mois (Gartner), mais seulement 17% l'ont réellement déployée en production. Cause racine : **la confiance** — les entreprises ne sont pas prêtes à déléguer la décision à des systèmes qu'elles ne peuvent pas pleinement contrôler, expliquer et gouverner. **Critique de l'angle mort des hyperscalers** Microsoft (Azure AI Agent Service/Framework), Google (Vertex AI Agent Builder/Engine) et AWS (Bedrock multi-agent) dominent le paysage mais partagent un angle mort : **la gouvernance décisionnelle**. Limitations spécifiques : Azure manque d'orchestration décisionnelle et de traçabilité d'audit intégrées (de plus en plus exigées par les entreprises). Google Vertex AI laisse largement à l'utilisateur l'application des politiques, les guardrails et la journalisation des décisions. AWS Bedrock s'appuie sur le LLM comme décideur de facto plutôt que sur une couche de raisonnement dédiée. **Problème d'architecture partagé** : la dépendance au LLM comme orchestrateur de facto — entité qui à la fois raisonne et décide. Résultat : les entreprises héritent de **pipelines de décision opaques** où la justification des choix de l'agent est inaccessible. Sans séparation explicite raisonnement / application des politiques / exécution → la responsabilité s'effondre et les dirigeants hésitent à valider des systèmes agentiques impossibles à auditer ou expliquer. **Forces des hyperscalers reconnues** : scalabilité massive (compute illimité, disponibilité mondiale), écosystèmes et intégrations riches (boîtes à outils, API, connecteurs), infrastructure et support de confiance (sécurité, conformité, SLA), innovation rapide et accès aux modèles. Mais l'échelle et la conformité au niveau infrastructure ne se traduisent PAS en gouvernance au niveau décision. **La limitation fondamentale des LLM, cause du manque de fiabilité** Les LLM sont probabilistes, chargés de prédire le prochain token. Ils n'ont **jamais été conçus pour raisonner** et livrer la meilleure solution à une requête. Reconnaissance de patterns et génération de langage extraordinaires MAIS **absence de raisonnement déterministe et de causalité vérifiable**. Cette architecture explique pourquoi les agents hallucinent, sortent des rails, prennent des décisions inexplicables et génèrent des sorties opaques impossibles à tracer ou auditer. **Prédiction Gartner** : **40% des projets d'IA agentique annulés d'ici 2027** pour coûts excessifs, ROI flou et contrôles de risque inadéquats causés par l'absence de gouvernance possible. Le marché se consolide : la prochaine phase de maturité ne tient **pas à des modèles plus gros, mais à des décisions meilleures et traçables**. **La solution Hypergraph Database de Rippletide** **Innovation cœur** : dépasser les limitations inhérentes des LLM qui empêchent le déploiement d'agents fiables, conformes et gouvernables. Représenter toutes les données dans un **hypergraphe unifié** unique ; l'agent procède étape par étape, **raisonnant véritablement** et évaluant à chaque étape la meilleure décision avant d'exécuter. **3 résultats enterprise-grade** : (1) **Fiabilité** : **taux d'hallucination <1%** pour les agents en production (vs approches purement LLM probabilistes) (2) **Conformité by design** : des **guardrails embarqués dans la base** pris en compte à chaque décision. L'architecture hypergraphe garantit que certaines parties du graphe sont inaccessibles → l'agent adhère toujours aux règles. Guardrails **sur mesure** selon le contexte et l'environnement réglementaire de l'entreprise. (3) **Gouvernance by design** : agent **auditable à tout moment**, toutes les décisions **tracées et vérifiables** via la structure hypergraphe. **Concept Decision Layer / Decision Core** **Couche critique de l'Agentic Enterprise** : couche de raisonnement dédiée, séparée de l'orchestration LLM. Ajoute la logique décisionnelle rigoureuse et la gouvernance absentes des conceptions antérieures. Séparation explicite raisonnement / application des politiques / exécution. **Cas d'usage 1 : Autonomous Coding Agent** Génère du code, corrige des bugs, déploie du logiciel. Sans gouvernance : un risque (incident de l'effacement de base de données). Avec Decision Layer : vérifie les plans contre une liste d'« actions sûres », écrit du code et lance des tests en autonomie, le déploiement en production requiert un OK humain sauf changement à faible risque, **se souvient des incidents passés** via la mémoire hypergraphe (ne répétera pas une migration dangereuse ayant causé une panne). Agit comme un développeur junior : prend des initiatives mais sait quand demander une approbation. Pourrait à terme gérer des **workflows SDLC entiers** du ticket au déploiement (prédiction BCG : déploiement d'applications testées via pipelines sur approbation humaine — la Decision Layer rend cela sûr et acceptable pour les CTO/CIO). **Cas d'usage 2 : Autonomous Analyst Agent** Prépare rapports analytiques et recommandations. Avec Decision Layer : fait en secondes ce qu'une équipe d'analystes ferait en jours, agrège les données des silos, applique les règles métier, produit le rapport, **justifie chaque insight par des données traçables**. Exemple : « Les ventes ont baissé de 5% à cause d'une rupture de stock dans la Région X (faits ERP/CRM) → je recommande de réallouer l'approvisionnement : Policy 14, plans de mitigation ». Au lieu d'un graphique boîte noire : une explication. Raisonnement **auditable par les régulateurs et auditeurs internes** (critique en finance/santé). **Vision** : les agents IA passent de prototypes fragiles → **collègues de confiance** gérant les opérations métier cœur avec la cohérence, la précision et la conformité d'un professionnel chevronné.

TOON - Token-Oriented Object Notation: JSON for LLMs at half the token cost

Wed, 22 Oct 2025 00:00:00 GMT

TOON est un format de sérialisation de données innovant conçu spécifiquement pour optimiser les appels aux modèles de langage volumineux. Contrairement à JSON, qui requiert une syntaxe verbale avec guillemets et accolades répétitifs, TOON réduit drastiquement la consommation de jetons—ressource directement facturable dans les interactions avec les LLM. Le projet démontre des réductions comprises entre 30 et 60% de jetons comparé à JSON, avec certains scénarios atteignant jusqu'à 65% d'économies selon les données structurées. L'architecture du format fusionne les concepts de YAML (indentation pour la hiérarchie) avec CSV (format tabulaire pour les données uniformes). Cette approche hybride s'avère particulièrement efficace pour les structures répétitives—collections d'objets identiques où chaque enregistrement partage les mêmes champs. Les syntaxes minimales éliminent les délimiteurs redondants, n'utilisant que des espaces pour indiquer l'imbrication et des virgules pour les séparations internes. Techniquement, TOON encode les métadonnées critiques dans les en-têtes d'arrays : `key[N]{field1,field2}:` indique N éléments avec champs spécifiés. Cette approche explicite améliore la validation par les LLM et facilite l'analyse de structures complexes. Les benchmarks révèlent une précision de récupération de données de 86,6% versus 83,2% pour JSON, démontrant que la compacité ne sacrifie pas la compréhension du modèle. Les cas d'usage s'étendent des exports de données analytiques aux listes de référentiels GitHub, en passant par les commandes de commerce électronique imbriquées. Pour les organisations gérant des volumes massifs de requêtes LLM, cette optimisation génère des économies substantielles aux coûts d'API, tandis que les développeurs bénéficient d'une syntaxe plus lisible qu'une compression binaire conventionnelle. Le projet, créé le 22 octobre 2025 par Johann Schopplich, représente une réponse pragmatique à un problème économique concret : chaque jeton consommé dans une interaction LLM a un coût financier direct. En réduisant de moitié la verbosité de JSON tout en maintenant—voire améliorant—la compréhension par le modèle, TOON offre un avantage compétitif immédiat pour les applications intensives en IA. L'innovation réside dans l'équilibre entre optimisation technique et lisibilité humaine. Contrairement aux formats de compression binaire qui deviennent opaques, TOON reste interprétable, facilitant le débogage et la maintenance. Cette caractéristique s'avère cruciale dans les environnements de production où la transparence des données échangées avec les LLM devient un enjeu de gouvernance et de conformité.

MCP-UI: The Future of Agentic Interfaces (Conference Talk)

Sat, 18 Oct 2025 00:00:00 GMT

**Problématique Double et Solution** Liad Yosef (AI & MCP Lead chez Monday.com, co-modérateur du UI work group) présente MCP-UI comme solution à un problème double. Premièrement, les interfaces textuelles créent des murs de texte pour les utilisateurs. Deuxièmement, et plus critique, les fournisseurs (Shopify, Airbnb, Amazon) **perdent leur identité** lorsqu'ils envoient uniquement du texte - le chat décide de l'affichage, les privant de leur place dans la chaîne de valeur. MCP-UI permet à chaque application d'envoyer des "chunks d'UI" - morceaux de leur identité - préservant reconnaissance visuelle et user experience perfectionée sur années. **Architecture Technique et Sécurité** MCP-UI est un **protocole ouvert** + SDK pour envoyer UI via MCP et standardiser communication host/UI. L'architecture repose sur **sandboxed iframes** garantissant sécurité : le code UI n'accède pas à l'origin du host, ne peut voler cookies/mémoire, communique uniquement via **post messages**. Trois types de contenu supportés : URLs externes, HTML brut, **remote DOM** (concept puissant séparant définition structure et rendering - même serveur MCP peut envoyer réponse identique à différents clients qui la rendront avec leurs propres composants). **Spectrum de Communication et État** MCP-UI définit un **spectrum de communication** représentant niveaux de responsabilité UI sur actions utilisateur : **(1) Notify** - UI exécute action backend et notifie chat ; **(2) Tool call** - UI demande trigger outil spécifique ; **(3) Prompt** - UI demande exécution prompt ; **(4) Intent** - UI envoie intention utilisateur, host décide quoi faire. Cette architecture **islands** (îles UI différentes composées dans contexte unique) nécessite gestion état sophistiquée sur **4 niveaux** : agent context (pour flow agentique), internal app state (préférences, steppers via cookies/localStorage), backend (data non pertinente pour flow agentique mais nécessaire synchronisation), et état partagé entre composants. **Démonstration Concrète : Sprint Management** La démo montre manager ingénierie demandant "sprint status". Au lieu de texte inutile, MCP-UI retourne **widget interactif Monday** avec breakdown visuel. Clic sur "stuck tasks" → affiche tâche "implementing authentication" assignée Sarah. Clic "analyze" → communication mechanism envoie prompt à agent qui, connecté à Gmail via autre serveur MCP, **fetch emails automatiquement** découvrant Sarah malade, Jordan connaît code. Widget injecte analyse colorisée suggérant reassign Jordan. Clic "reassign" → message intent déclenche tool call MCP complétant flow. Cruciale : **provider n'a pas créé intégration Gmail** - agent a fait connexion avec contexte existant. **Theming Multi-Layers** Pour éviter expérience "compilation d'UIs tierces", MCP-UI supporte **theming sophistiqué** : custom CSS (Shopify l'implémente déjà), CSS variables, theme tokens, et **remote DOM** (le plus puissant - UI distante rendue avec composants host, garantissant cohérence visuelle tout en préservant structure/interactions provider). **Adoptants et Ecosystem** Adoption massive déjà : **Shopify full deployment**, Postman, Goose, Libra chat (hosts) ; **Hugging Face** (tous spaces exposés MCP-UI), 11 Labs, MCP storefront (providers). SDKs communautaires Ruby, Python, TypeScript, Go. Projet communautaire sur **mcpui.dev** avec guides complets. **Vision Future : Web Fragmenté Recomposé** Vision transformative : aujourd'hui on ouvre 10 tabs différentes (Amazon, Calendar, Booking) pour tâche unique (planifier anniversaire), chacune avec UI complexe dont 90% irrelevant. Future : assistant personnel compose **atomes d'UI** de providers - Google Calendar envoie chunk event, Amazon chunk product list, Booking chunk listings+map. Aucune intégration provider-to-provider nécessaire - assistant a contexte complet. Résultat : **apps déconstructibles** en composants réutilisables, Jarvis accessible car overhead intégration disparu. **Challenges Roadmap** Trois défis majeurs : **(1) Auth/SSO** - actuellement état baked in context/UI ou auth in-UI, besoin SSO seamless ; **(2) Clients natifs** - ChatGPT/Claude vont natif, beaucoup ne supportent pas iframes/webviews, exploration **abstract payload** convertible HTML ou native avec **capabilities negotiation** ; **(3) Standardisation adoption** - technologie ready, besoin momentum communautaire.

The AI Platform Shift: Redefining What Software Is, and How Leaders Should Respond

Wed, 15 Oct 2025 00:00:00 GMT

Philippe Ensarguet soutient que l'intelligence artificielle représente une transformation fondamentale du logiciel, comparable aux grandes révolutions informatiques précédentes, et non une simple amélioration incrémentale. Son analyse s'appuie sur l'observation que chaque changement de plateforme informatique a radicalement redéfini la nature même du logiciel : de l'ère des mainframes aux ordinateurs personnels, puis au web, aux mobiles, et maintenant à l'IA. La thèse centrale est que les changements de plateforme ne se contentent pas d'améliorer les logiciels existants, mais réécrivent fondamentalement comment les applications sont conçues, développées et utilisées. Chaque transition a créé de nouvelles possibilités qui étaient impossibles ou impensables dans le paradigme précédent. L'IA suit cette trajectoire historique en introduisant des capacités qualitativement différentes. Ensarguet identifie cinq caractéristiques définissant le logiciel de l'ère IA : il sera adaptatif (ajustant son comportement selon le contexte et l'utilisateur), composable (assemblant dynamiquement des capacités modulaires), piloté par l'intention (comprenant les objectifs plutôt que suivant des commandes explicites), conscient du contexte (intégrant des informations situationnelles complexes), et conversationnel (privilégiant le dialogue naturel aux interfaces traditionnelles). L'article met en garde contre la tentation la plus courante des organisations établies : simplement ajouter de l'IA à leurs workflows et produits existants. Cette approche, selon Ensarguet, manque l'opportunité de réimaginer fondamentalement ce que le logiciel peut accomplir. Il compare cette erreur aux tentatives initiales de "porter" des applications desktop vers le web sans repenser l'expérience utilisateur pour tirer parti des capacités uniques du web. Pour les leaders technologiques, Ensarguet recommande une stratégie d'adaptation proactive. Plutôt que d'attendre l'émergence de meilleures pratiques établies, les organisations doivent expérimenter activement avec de nouveaux modèles d'interaction et construire des architectures AI-native. Cette approche nécessite d'accepter l'incertitude et l'ambiguïté inhérentes aux transitions de plateforme. L'article souligne l'avantage structurel dont disposent les startups dans ces moments de transition. Sans l'encombrement de systèmes legacy et de modèles mentaux établis, elles peuvent explorer plus librement les nouvelles possibilités. Les entreprises établies doivent consciemment surmonter leur inertie organisationnelle pour rivaliser avec cette agilité. Les implications pratiques incluent la nécessité de repenser les problèmes fondamentaux que le logiciel cherche à résoudre, plutôt que de simplement optimiser les solutions existantes. Les équipes doivent explorer de nouveaux paradigmes d'interaction où l'utilisateur exprime ses intentions et le contexte plutôt que de suivre des workflows prédéfinis. Les systèmes doivent être conçus pour être flexibles et adaptatifs dès le départ. Ensarguet conclut avec une observation puissante : "Les changements de plateforme sont inévitables. La rapidité avec laquelle nous nous y adaptons ne l'est pas." Cette citation encapsule l'impératif stratégique pour les leaders technologiques : reconnaître que la transformation IA n'est pas optionnelle, mais que le choix du moment et de la manière de s'adapter peut déterminer le succès ou l'échec organisationnel. Le futur du logiciel ne sera pas constitué de versions améliorées des applications actuelles, mais d'applications fondamentalement différentes que nous commençons tout juste à imaginer.

Everything you need to know about building ChatGPT apps

Fri, 10 Oct 2025 00:00:00 GMT

L'équipe Gadget partage son retour d'expérience après plusieurs jours de développement intensif sur le nouveau SDK ChatGPT Apps d'OpenAI. L'article détaille les trois composantes essentielles d'une application ChatGPT : un serveur MCP conforme au Model Context Protocol, une extension permettant d'afficher des interfaces utilisateur dans les conversations, et optionnellement un serveur OAuth 2.1 avec OIDC pour l'authentification. Pour la construction de serveurs MCP, l'article recommande d'utiliser le transport Streamable HTTP plutôt que la version SSE présentée dans les exemples officiels d'OpenAI. Les exemples fournis utilisent une map de sessions en mémoire inadaptée aux plateformes serverless. Le MCP Inspector est conseillé pour le débogage initial car les messages d'erreur de ChatGPT sont peu informatifs. L'implémentation de l'authentification OAuth 2.1 représente un changement de paradigme : contrairement à l'usage habituel où l'on redirige vers un provider externe comme Google, ici l'application doit elle-même être le provider OAuth pour OpenAI. Cela nécessite d'implémenter les endpoints OIDC de découverte permettant à ChatGPT d'obtenir des tokens. La fonctionnalité la plus innovante est la possibilité de servir des widgets UI interactifs aux utilisateurs. Ces widgets sont en réalité des iframes sandboxées qui chargent un document HTML statique, mis en cache à l'installation de l'application. Cette contrainte impose le développement d'applications client-side single-page, sans rendu serveur dynamique. L'équipe recommande Vite pour la compilation TypeScript, le bundling, le hot-module-reloading et le support Tailwind. Un plugin Vite dédié est disponible sur GitHub. Pour la communication avec le backend depuis un widget, deux approches existent. L'objet `window.openai` injecté par OpenAI permet d'appeler les outils MCP avec l'authentification gérée automatiquement et une visibilité pour le LLM sur les interactions. L'alternative via `fetch` direct nécessite de gérer l'authentification manuellement et perd la conscience contextuelle du LLM. Le CORS constitue un défi majeur avec trois configurations distinctes à gérer : les routes MCP, les routes OAuth 2.1, et les assets frontend. Pour les deux premières, un header permissif `Access-Control-Allowed-Origin: *` est recommandé car l'authentification sécurise déjà les appels. Pour les assets de widgets, il faut autoriser l'origin `https://web-sandbox.oaiusercontent.com` utilisée par OpenAI. L'article conclut que l'écosystème est encore très jeune mais prometteur, avec des templates prêts à l'emploi disponibles chez Gadget pour accélérer le démarrage.

From RAG to Rigor Mortis: Why Retrieval-Augmented Generation looks like dying

Wed, 08 Oct 2025 00:00:00 GMT

L'article examine le déclin potentiel de la Génération Augmentée par Récupération (RAG) face à l'évolution rapide de la technologie IA. L'auteur explique comment le RAG est apparu comme une solution aux fenêtres de contexte limitées des premiers modèles IA, permettant aux systèmes de récupérer et d'utiliser des fragments de documents pertinents. Cependant, avec l'expansion rapide des fenêtres de contexte dans les modèles IA modernes (passant de 8K à potentiellement des millions de tokens), le RAG pourrait devenir obsolète. L'article met en évidence cinq défis clés du RAG qui contribuent à son déclin potentiel. Premièrement, le découpage (chunking) des documents fait perdre le sens contextuel, fragmentant l'information de manière artificielle. Deuxièmement, les technologies d'embedding ont des limitations inhérentes dans leur capacité à capturer pleinement la richesse sémantique du contenu. Troisièmement, la recherche hybride ajoute une complexité inutile au processus de récupération d'information. Quatrièmement, le reranking introduit de la latence et des coûts supplémentaires dans le pipeline de traitement. Enfin, la gestion de l'infrastructure RAG devient de plus en plus complexe et coûteuse à maintenir. L'auteur argumente que les technologies émergentes comme Claude Code démontrent un changement vers une recherche directe et riche en contexte, sans mécanismes de récupération complexes. Puisque les modèles IA peuvent maintenant gérer des documents entiers dans leurs fenêtres de contexte, l'infrastructure RAG élaborée pourrait devenir superflue. Cette évolution représente un changement de paradigme dans la manière dont nous concevons et construisons des systèmes IA. Plutôt que de fragmenter et récupérer l'information, les systèmes futurs pourront traiter directement de vastes quantités de contexte, permettant une compréhension plus holistique et nuancée. L'article souligne que cette transition a des implications importantes pour les organisations et les développeurs qui ont investi massivement dans l'infrastructure RAG. Les compétences nécessaires pour construire des systèmes IA évoluent, passant de l'ingénierie de récupération complexe à la conception de systèmes agentiques capables de naviguer intelligemment dans de grands espaces contextuels. L'auteur suggère que les organisations doivent se préparer à cette transition technologique, reconnaissant que le RAG n'était qu'une étape intermédiaire dans l'évolution de l'IA. Les futurs systèmes privilégieront la compréhension du contexte complet plutôt que la récupération fragmentée. La citation centrale résume parfaitement cette perspective : "Le RAG n'a jamais été la destination—c'était un détour temporaire." Cette affirmation encapsule l'idée que le RAG était une solution pragmatique à des limitations techniques qui sont maintenant en train d'être dépassées par l'innovation technologique rapide. En conclusion, l'article appelle à une réévaluation des architectures IA actuelles et à une anticipation des paradigmes émergents qui remplaceront les approches RAG traditionnelles.

CEA unveils ExpressIF 3: RISC-V AI SoC for Edge Computing

Wed, 01 Oct 2025 00:00:00 GMT

Le CEA (Commissariat à l'énergie atomique et aux énergies alternatives) dévoile **ExpressIF 3**, dernière génération de son **system-on-chip (SoC) IA basé sur RISC-V** conçu pour les applications d'edge computing. Le produit représente un jalon significatif pour la **souveraineté technologique européenne**, offrant une alternative aux architectures de puces américaines et asiatiques dominantes tout en fournissant des **capacités d'accélération IA** spécialisées pour les systèmes embarqués. **Fondation RISC-V : un choix stratégique** La décision du CEA de s'appuyer sur **l'architecture de jeu d'instructions ouverte RISC-V** plutôt que sur ARM ou x86 propriétaires reflète des considérations stratégiques de souveraineté. La nature ouverte de RISC-V permet un **contrôle complet de la conception de la puce** sans frais de licence ni dépendances géopolitiques. Cette approche est particulièrement importante pour les industries européennes exigeant un accès garanti de long terme à la technologie des puces, indépendamment des tensions commerciales internationales. **Architecture d'accélération IA** ExpressIF 3 intègre des **accélérateurs de réseaux de neurones dédiés** optimisés pour les charges d'inférence typiques des déploiements en edge. L'architecture est conçue pour l'exécution efficace de réseaux de neurones convolutifs (CNN), de transformers et d'autres modèles IA courants tout en maintenant une **faible consommation énergétique**, critique pour les appareils sur batterie. Les performances ciblent les applications nécessitant une **inférence en temps réel** : véhicules autonomes, robotique industrielle, caméras intelligentes, capteurs IoT. **Focalisation edge computing** La philosophie de conception privilégie le déploiement **en périphérie plutôt que dans le cloud**. Plutôt que d'envoyer les données vers des serveurs distants pour traitement, ExpressIF 3 permet **l'inférence IA sur l'appareil**, réduisant la latence, améliorant la confidentialité et éliminant les dépendances de connectivité. Cette approche edge-first est de plus en plus importante pour les applications exigeant : des temps de réponse immédiats (véhicules autonomes), la préservation de la vie privée (dispositifs médicaux), un fonctionnement dans des environnements à connectivité contrainte (contextes industriels). **Efficacité énergétique** Métrique critique pour les systèmes embarqués : les **watts par inférence**. ExpressIF 3 est optimisé pour une **consommation à l'échelle du milliwatt** tout en maintenant des performances acceptables. Cette efficacité est obtenue par : des accélérateurs IA spécialisés évitant l'inefficacité des CPU généralistes, un clock gating agressif réduisant la consommation au repos, une hiérarchie mémoire minimisant les accès DRAM coûteux, un ajustement tension/fréquence adapté à l'intensité de la charge. **Écosystème logiciel** Le matériel seul ne suffit pas — une adoption réussie exige une **stack logicielle complète**. Le CEA développe : chaînes d'outils et compilateurs RISC-V, support des frameworks IA (TensorFlow Lite, ONNX), piles de drivers, cartes de développement, designs de référence, documentation et tutoriels. La construction de l'écosystème représente un effort pluriannuel mais essentiel pour l'adoption commerciale. **Applications cibles** Marchés prioritaires : **automobile** (systèmes ADAS, surveillance d'habitacle, conduite autonome), **industrie** (maintenance prédictive, inspection qualité, robotique), **IoT** (caméras intelligentes, réseaux de capteurs, passerelles edge), **dispositifs médicaux** (diagnostics portables, équipements de monitoring). Chaque domaine priorise différents compromis entre performance, consommation et coût. **Stratégie industrielle européenne** ExpressIF 3 s'inscrit dans **l'effort européen plus large** d'indépendance technologique. Les dépendances aux plateformes cloud américaines et à la fabrication de puces asiatique sont identifiées comme des vulnérabilités stratégiques. Les investissements français et européens dans la conception et la production domestiques de puces visent à **réduire ces dépendances** tout en créant des industries domestiques compétitives. **Paysage concurrentiel** ExpressIF 3 est en concurrence avec : Nvidia Jetson (haute performance, consommation plus élevée), Google Coral (inférence edge basée TPU), Intel Movidius (focalisation vision par ordinateur), SoCs ARM avec NPU. **La différenciation provient de** : l'architecture RISC-V ouverte, l'origine européenne offrant des bénéfices de souveraineté, des optimisations spécifiques pour les applications cibles, un prix compétitif rendu possible par l'absence de licence ARM. **Voie de commercialisation** La transition du prototype de recherche au produit commercial exige : des partenariats avec des fonderies de semi-conducteurs pour la fabrication, l'engagement avec les intégrateurs systèmes et OEMs, des processus de certification pour les applications automobiles/médicales, des prix compétitifs malgré des volumes inférieurs à ceux des géants. Le succès démontrera la viabilité d'une **voie européenne** dans le domaine critique du matériel IA.

HOW CLAUDE CODE IS BUILT

Mon, 15 Sep 2025 00:00:00 GMT

L'article de Gergely Orosz offre un aperçu rare du développement de Claude Code, l'outil de développement basé sur l'IA d'Anthropic qui a rapidement généré plus de 500 millions de dollars de revenus annuels. À travers des entretiens avec les ingénieurs fondateurs Boris Cherny et Sid Bidasaria, ainsi que la cheffe de produit Cat Wu, l'article explore la genèse, l'architecture et l'approche d'ingénierie "AI-first" de cet outil révolutionnaire. Claude Code a débuté en septembre 2024 comme un prototype simple de Boris Cherny, capable initialement de seulement identifier la musique écoutée. La percée décisive est survenue en lui donnant accès au système de fichiers et aux commandes bash, lui permettant d'explorer les bases de code et de répondre à des questions en lisant et en suivant les imports de fichiers de manière autonome. Cette découverte a révélé un "surplus de produit" : la capacité du modèle existait déjà, mais aucun produit ne l'exploitait pleinement. Le prototype a rapidement gagné en popularité chez Anthropic, avec 50% des ingénieurs l'utilisant quotidiennement cinq jours seulement après une version de test interne en novembre 2024. Malgré un débat interne sur le maintien de l'outil comme avantage concurrentiel, Anthropic a décidé de le lancer publiquement pour approfondir sa compréhension de la sécurité et des capacités des modèles. L'équipe, initialement composée de Boris seul, a atteint une dizaine d'ingénieurs en juillet, travaillant avec une grande autonomie et un accent sur le prototypage rapide. L'utilité de Claude Code s'est étendue au-delà des développeurs, les data scientists l'adoptant également pour les requêtes et les visualisations. L'outil a contribué à une augmentation de 67% du nombre de pull requests chez Anthropic, malgré un doublement des effectifs d'ingénierie, démontrant un gain de productivité substantiel. La pile technologique de Claude Code est "sur distribution" pour le modèle Claude, utilisant des technologies que le modèle maîtrise déjà : TypeScript, React avec Ink pour l'interface utilisateur du terminal, Yoga pour la mise en page et Bun pour la construction et le packaging. Fait remarquable, environ 90% du code de Claude Code est écrit par Claude Code lui-même, illustrant une approche "dogfooding" poussée à l'extrême. L'architecture privilégie la simplicité, agissant comme une interface légère qui expose des outils et des hooks d'interface utilisateur au modèle Claude, lequel effectue la majeure partie du travail complexe. L'équipe affine constamment le système, supprimant souvent du code et simplifiant les prompts avec les nouvelles versions de modèles. Un aspect crucial est le système de permissions, conçu pour empêcher l'IA d'apporter des modifications irréversibles sans le consentement de l'utilisateur. Il offre un contrôle granulaire, permettant aux utilisateurs d'accorder des permissions une fois, pour les sessions futures, ou de les refuser, avec des options de configuration à plusieurs niveaux. Le processus de développement se caractérise par une vitesse extrême. L'équipe publie 60 à 100 versions internes par jour et une version externe quotidienne. Le prototypage est exceptionnellement rapide : Boris Cherny a développé environ 20 prototypes d'interface utilisateur pour une fonctionnalité de "liste de tâches" en seulement deux jours, itérant rapidement en fonction des prompts et des retours. Cette itération rapide, rendue possible par les agents IA, accélère considérablement la conception et l'implémentation de nouvelles fonctionnalités, modifiant fondamentalement le rythme du prototypage. Claude Code introduit également des fonctionnalités innovantes d'expérience utilisateur pour le terminal, tirant parti de la nature interactive des terminaux alimentés par les LLM.

MCP remplace le navigateur : Voici comment les développeurs devraient se préparer

Mon, 15 Sep 2025 00:00:00 GMT

Le Protocole de Contexte de Modèle (MCP) est en train de redéfinir la manière dont les agents d'IA interagissent avec les services en ligne, marquant un changement significatif par rapport à la navigation web traditionnelle centrée sur l'utilisateur. Peter Aideloje explore comment le MCP est en passe de remplacer le navigateur, ce que cette transition implique pour les développeurs, et comment ils peuvent s'y préparer. Le MCP est un protocole ouvert qui permet aux agents d'IA de se connecter, d'accéder et d'interagir de manière sécurisée avec des outils externes, des sources de données et des API. Son objectif principal est de fournir aux agents d'IA un accès structuré et fiable au contexte et aux fonctionnalités au-delà de leurs données d'entraînement. Contrairement à la navigation web où les humains interagissent avec des pages via un navigateur, le MCP permet à un agent d'IA de découvrir et d'invoquer des outils sur un serveur de manière autonome, en se basant sur l'entrée de l'utilisateur et l'objectif de l'IA. Cette approche offre un accès direct et structuré aux données ou aux fonctionnalités sans avoir besoin de parser le HTML ou de simuler des clics, réduisant ainsi les incohérences. Le potentiel du MCP à remplacer le navigateur traditionnel est alimenté par la délégation aux agents d'IA, les interactions directes avec des fonctionnalités structurées, l'exécution par intention et l'adoption croissante de l'IA dans l'industrie. Au lieu de naviguer, de filtrer et de remplir des formulaires, les utilisateurs exprimeront simplement ce qu'ils veulent, et le MCP permettra aux assistants de réaliser ces tâches. Pour les développeurs, en particulier les ingénieurs frontend, l'essor du MCP signifie un changement radical dans la conception des expériences numériques. Au lieu de créer des interfaces utilisateur pixel-perfect pour les humains, les développeurs devront construire des "sites web" orientés IA : des serveurs MCP qui exposent des fonctionnalités de manière compréhensible par les assistants. Ces serveurs ne livrent pas de HTML et de CSS, mais définissent des schémas clairs composés d'outils (fonctions que l'IA peut appeler), de ressources (données structurées en lecture seule) et de prompts (modèles réutilisables pour guider l'interaction de l'assistant avec les utilisateurs). La précision des schémas remplace le polissage de la mise en page. La sécurité évolue également, passant de modèles centrés sur l'humain à des interactions médiatisées par l'IA, nécessitant une réflexion sur les permissions, les limites de confiance, les pistes d'audit et la limitation de débit. Les API MCP doivent être conçues en priorité pour la compréhension machine, avec des contrats plus stricts, une gestion explicite des erreurs et des métadonnées plus riches. Pour se préparer, les développeurs doivent se familiariser avec le fonctionnement des serveurs MCP, concevoir des endpoints avec une intention claire, s'habituer aux modèles d'UX axés sur l'IA, s'attendre à une collaboration plus interfonctionnelle et s'impliquer tôt pour façonner l'avenir. Le MCP offre des opportunités pour des expériences utilisateur fluides et de nouveaux paradigmes UX, mais présente aussi des défis en matière de débogage du comportement de l'IA, de garantie de fiabilité et de construction de la confiance.

Block's Goose and the Future of Agentic Interfaces via Model Context Protocol

Mon, 25 Aug 2025 00:00:00 GMT

Le blog Goose de Block publie une plongée dans **MCP-UI**, technologie qui, selon l'équipe, condamne « les murs de texte sans fin » des conversations d'agents IA. L'article s'appuie sur un épisode du podcast « Wild Goose Case » réunissant les créateurs de MCP-UI, **Ido Salomon et Liad Yosef de Monday.com**, et **Andrew Harvard de Block**, pour explorer comment cette technologie redessine le futur des interfaces agentiques. **Le problème des interfaces texte-seulement** Demander à un agent de l'aide pour un achat aboutit aujourd'hui à un mur de texte : noms de produits, prix, descriptions, puis copier-coller d'URLs et onglets multiples — l'utilisateur refait tout le travail. Comme le résume Ido Salomon, tout le monde a connu ce moment de « rage quit » devant un assistant qui ne renvoie que du texte. Ces interfaces conviennent aux early adopters, pas au grand public. **MCP-UI : protocole et SDK** MCP-UI (Model Context Protocol User Interface) permet d'intégrer des **composants web riches et interactifs** directement dans les conversations d'agents. La philosophie est simple : pourquoi jeter des décennies d'expertise web UI/UX quand on peut l'augmenter avec l'IA ? Liad Yosef souligne que plus d'une décennie d'interfaces web perfectionnées pour les limites cognitives humaines ne doit pas disparaître avec les agents. Le système exploite les embedded resources de la spécification MCP : un serveur MCP peut retourner des composants UI au lieu de texte brut. Quatre apports clés : composants riches (catalogues, cartes de sièges, formulaires), **préservation de la marque** (Shopify garde son expérience), intégration sécurisée, et **compatibilité cross-platform**. **Fondations techniques** La sécurité prime : les composants sont rendus dans des **iframes sandboxées** qui ne communiquent avec l'hôte que par post messages, empêchant le code tiers de manipuler l'application parente. Trois types de contenu sont supportés : URLs externes, HTML brut, et remote DOM (rendu dans des workers séparés). Le démarrage est minimal : `createUIResource({ type: 'html', content: '<h1>Hello World</h1>' })`. **Démonstrations et écosystème** Les démos montrent un shopping visuel (catalogue Shopify interactif avec ajout au panier), la planification de voyage (sélection de siège sur carte visuelle, météo de destination automatique) et la découverte de restaurants (cartes avec photos, notes, menus, commande directe) — le tout sans quitter la conversation. Le succès repose sur quatre parties prenantes : développeurs d'agents (comme l'équipe Goose), développeurs de serveurs MCP, fournisseurs de services (Shopify, Square) et utilisateurs finaux. L'approche crée un **effet de réseau** : un composant implémenté une fois fonctionne sur tous les agents compatibles. **Vision** Au-delà d'interfaces plus jolies : une **révolution de l'accessibilité** (« quoi de plus accessible qu'un agent qui vous connaît et construit l'UI selon vos préférences ? ») et, à terme, une **générative UI** produisant des interfaces adaptées aux besoins de chaque utilisateur.

MCP-UI: The Future of Agentic Interfaces

Mon, 25 Aug 2025 00:00:00 GMT

**Le Problème des Interfaces Textuelles Pures** Les interfaces d'agents IA traditionnelles souffrent d'une limitation fondamentale : elles forcent les utilisateurs à consommer toute information via réponses textuelles. Lorsqu'on demande des recommandations produits, planification voyage ou recherche restaurants, on reçoit des murs de texte accablants avec descriptions, liens et données nécessitant copier-coller manuel et jonglage d'onglets. Cela défait l'objectif d'avoir un assistant intelligent et crée une expérience utilisateur médiocre, spécialement pour non-techniques. L'approche texte-seulement fonctionne pour early adopters mais crée des barrières à l'adoption mainstream, limitant l'utilité des agents pour tâches quotidiennes. **Architecture Technique de MCP-UI** MCP-UI (Model Context Protocol User Interface) est à la fois protocole et SDK permettant d'intégrer des composants web interactifs riches directement dans les conversations d'agents IA. Le système exploite les embedded resources de la spécification MCP, autorisant les serveurs MCP à retourner composants UI interactifs plutôt que texte brut. Ces composants sont rendus dans des **iframes sandboxed** qui communiquent avec l'application hôte uniquement via messages post sécurisés, garantissant que code tiers ne peut accéder ou manipuler l'application parente. L'implémentation supporte **trois types de contenu** : URLs externes (apps web existantes dans iframes), HTML brut (HTML custom avec CSS et JavaScript), et remote DOM (UI rendue dans workers séparés pour sécurité renforcée). Les développeurs peuvent commencer avec simples ressources HTML et progressivement enrichir avec fonctionnalités interactives. **Bénéfices Clés et Cas d'Usage** MCP-UI préserve décennies d'expertise web UI/UX tout en l'augmentant avec capacités IA. Il maintient l'identité de marque pour entreprises comme Shopify, fournit compatibilité cross-platform seamless entre différents agents IA, et crée un **network effect** où composants UI fonctionnent universellement une fois implémentés. La technologie adresse l'accessibilité en permettant aux agents de construire interfaces adaptées aux préférences et besoins individuels. Elle crée aussi standardisation, éliminant besoin d'intégrations séparées pour chaque plateforme IA. **Démonstrations Concrètes** Trois exemples compellants : **(1) Shopping Visuel** - catalogues Shopify avec images, prix et éléments interactifs où cliquer ajoute items au panier ; **(2) Planification Voyage** - cartes sélection sièges avion visuelles avec lookup météo automatique pour destinations ; **(3) Découverte Restaurants** - navigation restaurants locaux avec cartes photos, ratings, menus et capacités commande directe, tout dans le flux conversationnel. **Implications Futures** MCP-UI pointe vers une **révolution accessibilité** où agents construisent interfaces personnalisées, **générative UI** créant expériences sur-mesure pour utilisateurs individuels, **expériences multi-modales** s'étendant au-delà du visuel vers voix et composants mobiles natifs, et **standardisation cross-platform**. Le défi actuel est l'adoption plutôt que faisabilité technique, avec acteurs majeurs comme Shopify implémentant déjà support MCP sur tous leurs stores. **Détails Implémentation Technique** L'écosystème de stakeholders implique quatre groupes : développeurs agents implémentant support MCP-UI, développeurs serveurs MCP construisant composants UI, fournisseurs services créant interfaces riches, et utilisateurs finaux bénéficiant d'interactions intuitives. Démarrer nécessite code minimal - développeurs peuvent commencer avec ressources HTML basiques comme `createUIResource({ type: 'html', content: '<h1>Hello World</h1>' })` et étendre depuis là. La technologie est déjà supportée dans Goose et disponible via documentation complète et communauté Discord active. MCP-UI représente un shift fondamental des interactions IA text-heavy vers expériences riches, visuelles et intuitives qui font le pont entre le web tel qu'on le connaît et le futur agentique en construction.

Model Once, Represent Everywhere: UDA (Unified Data Architecture) at Netflix

Thu, 12 Jun 2025 00:00:00 GMT

Netflix présente UDA (Unified Data Architecture), une infrastructure révolutionnaire basée sur un knowledge graph pour résoudre la fragmentation chronique des modèles de données à l'échelle de son écosystème Content Engineering. Le problème fondamental : des concepts métier centraux comme "actor" ou "movie" sont redéfinis indépendamment dans chaque système (GraphQL Gateway, asset management, media computing), créant duplication, incohérences terminologiques, problèmes qualité, et connectivité limitée. **Architecture fondamentale : Knowledge Graph RDF/SHACL** UDA adopte RDF et SHACL comme fondations techniques, mais confronte des défis opérationnels majeurs à l'échelle entreprise : RDF manquait d'information model utilisable, SHACL n'était pas conçu pour données enterprise avec schémas locaux et clés typées, les équipes manquaient de pratiques d'authoring partagées, et l'outillage ontologie n'offrait pas support pour modélisation collaborative. Solution : information model "named-graph-first" où chaque named graph se conforme à un governing model, lui-même named graph dans le knowledge graph. **Upper Metamodel : Le modèle de tous les modèles** Upper constitue le langage formel pour décrire domaines métier ou systèmes, organisant concepts en domain models : vocabulaires contrôlés définissant classes d'entités clés, attributs, relations. Crucially, Upper est bootstrapping upper ontology : auto-référentiel (modélise lui-même), auto-descriptif (définit concept de domain model), auto-validant (conforme à son propre modèle). Upper projette vers API Java Jena-based et schéma GraphQL fédéré dans Enterprise Gateway. Comme tous domain models sont extensions conservatives d'Upper, intégration seamless runtime garantit sémantique données cohérente. **Mappings et Projections : Connexion et Automation** Mappings connectent éléments domain models aux data container representations (GraphQL resolvers, Data Mesh sources, Iceberg tables). Tout est adressable : du domain model à l'attribut spécifique, du table Iceberg à la colonne individuelle. Mappings permettent discovery bidirectionnelle : du concept métier au système physique stockant données, et inverse. Projections produisent conteneurs concrets implémentant caractéristiques dérivées du domain model enregistré, avec transpilation automatique vers GraphQL/Avro schemas preservant sémantique. **Adopteurs Production : PDM et Sphere** PDM (Primary Data Management) gère vocabulaires contrôlés authoritative utilisant modèle SKOS (W3C). Prend domain model comme input, génère UI automatiquement, provisionne Domain Graph Services et pipelines Data Mesh via projections UDA. Vocabulaires consommateurs ignorent SKOS—travaillent avec terminologie domaine familière. Sphere : système reporting opérationnel self-service UDA-powered. Discovery via concepts métier ("actors", "movies"), non tables techniques. UDA knowledge graph génère requêtes SQL via graph traversal, éliminant joins manuels et médiation technique. Métadonnées agrégées présentées avec vocabulaire unifié, boundaries et islands data landscape identifiées automatiquement. **Impact transformationnel** UDA transforme modèles conceptuels en control plane actif : non seulement documente concepts, mais génère schémas, provisionne services, orchestre data movement, et enforce consistency automatiquement. Futurs développements : support Protobuf/gRPC, matérialisation knowledge graph instance data, résolution challenges Graph Search initiaux ayant inspiré ce travail.