Cet article présente les principaux programmes tels qu'ils se présentent en septembre 2026, décrit pas à pas le chemin jusqu'à la demande et cite les erreurs typiques qui peuvent coûter le financement.

Quels types de financement existent

Il existe quatre types de financement, et ils se distinguent davantage par leur logique que par leur montant. Une subvention couvre une partie des coûts éligibles et n'est pas remboursée, mais elle exige une demande avant le début du projet et, à la fin, un justificatif d'emploi des fonds (Verwendungsnachweis). Un prêt aidé passe par votre banque (Hausbank) et peut comporter une part de subvention dans les niveaux supérieurs. La Forschungszulage est une aide fiscale à la recherche et au développement. Les offres de conseil ne versent pas d'argent, mais aident à situer un projet.

Un projet d'IA n'est pas éligible du seul fait du mot-clé IA, mais lorsqu'il correspond à l'objet d'un programme : recherche et développement, numérisation des processus et des produits ou conseil externe. Pour vos recherches, il est utile de savoir que le ministère fédéral de l'Économie s'appelle désormais BMWE (auparavant BMWK) et le ministère de la Recherche BMFTR.

Les programmes fédéraux en bref

Au niveau fédéral, cinq instruments sont particulièrement pertinents pour les projets d'IA en 2026, avec des statuts très différents.

• ZIM (Zentrales Innovationsprogramm Mittelstand, programme central d'innovation pour les PME). Le BMWE finance les projets de recherche et développement des PME, seules ou avec des établissements de recherche, ainsi que des réseaux d'innovation et des études de faisabilité. Depuis le 7 juillet 2026, un arrêt temporaire des demandes s'applique : ZIM n'accepte actuellement plus de nouvelles demandes, une réouverture est visée pour début 2027 et dépend du budget 2027. Les demandes déjà déposées continuent d'être instruites.
• KMU-innovativ. Le BMFTR finance des projets de recherche et développement à risque dans des technologies clés, dont les technologies de l'information et de la communication. La procédure comporte deux étapes : d'abord une esquisse de projet, puis la demande. Les dates limites sont le 15 avril et le 15 octobre, la prochaine étant le 15 octobre 2026 (situation en septembre 2026). Page du programme KMU-innovativ.
• Forschungszulage (aide fiscale à la recherche). Toute entreprise imposable en Allemagne peut en bénéficier, quels que soient sa taille et son secteur. La BSFZ certifie d'abord qu'il s'agit de recherche et développement, puis l'aide est demandée au centre des impôts après la clôture de l'exercice, y compris pour des projets déjà réalisés. Pour 2026, elle a été élargie dans le cadre de l'Investitionssofortprogramm (programme d'investissement immédiat). Organisme de certification de la Forschungszulage.
• ERP-Förderkredit Digitalisierung (511, 512). Par l'intermédiaire de votre banque, la KfW finance la numérisation en trois niveaux, de l'informatique, des logiciels et du cloud à la numérisation des processus, la sécurité informatique et la formation, jusqu'à des projets plus importants, y compris explicitement l'utilisation de l'IA sur les données de l'entreprise. La demande doit être déposée avant le début du projet, et le premier niveau exige au préalable un KfW-Digitalisierungs-Check. Page produit de la KfW.
• Mittelstand-Digital Zentren. Le BMWE finance un accompagnement gratuit et neutre vis-à-vis des fournisseurs sur la numérisation, l'IA et la sécurité informatique, avec des formateurs IA dans les centres. Aucun argent n'est versé. Le réseau actuel prend fin progressivement d'ici fin 2026, et à partir du 1er janvier 2027 un nouveau réseau lui succède avec un accent supplémentaire sur la sécurité informatique, toujours gratuit pour les PME. Mittelstand-Digital.

Pour les consortiums associant science et industrie, la directive du BMFTR sur les projets phares d'IA dans les chaînes de valeur est également ouverte, avec une date limite pour les esquisses de projet fixée au 1er novembre 2026 (situation en septembre 2026).

Les financements au niveau européen

Au niveau européen, quatre voies s'offrent aux projets d'IA : les European Digital Innovation Hubs, l'EIC Accelerator, le financement en cascade et le programme pour une Europe numérique.

• European Digital Innovation Hubs (EDIH). Des consortiums régionaux proposent des services gratuits ou subventionnés, comme « test before invest », des formations et une aide à la recherche d'investisseurs, avec des priorités telles que l'IA et la cybersécurité. Présentation de la Commission européenne.
• EIC Accelerator. Le Conseil européen de l'innovation soutient des start-up et PME individuelles porteuses d'innovations de rupture proches du marché, sous forme de subvention, de prise de participation ou des deux. Les propositions courtes peuvent être déposées à tout moment, et la prochaine date limite pour les propositions complètes est le 4 novembre 2026 (situation en septembre 2026). EIC Accelerator.
• Financement en cascade. Des consortiums de projets financés par l'UE reversent une partie de leur budget à des start-up et PME par des appels ouverts, sous forme de montants forfaitaires, de prix ou de bons, avec des procédures simplifiées, par exemple pour de petites expérimentations et des projets pilotes. Les appels restent ouverts au moins deux mois sur le portail Funding & Tenders de l'UE. Guide de la Commission (PDF).
• Programme pour une Europe numérique. La Commission lance des appels pour l'IA, le calcul haute performance, la cybersécurité et les compétences numériques. Les PME en bénéficient le plus souvent indirectement, par exemple via les EDIH. Page du programme.

Les programmes régionaux en Rhénanie-Palatinat

En Rhénanie-Palatinat, les aides du Land sont attribuées par l'ISB, et quatre programmes sont particulièrement pertinents pour les projets d'IA.

• InnoTop. Financement technologiquement neutre d'études de faisabilité et de projets de recherche et développement pour des produits, procédés et services nouveaux ou améliorés, destiné aux PME et aux SmallMidCaps.
• Innovationsgutschein (FuE-Auftrag). Un chèque innovation : subvention pour les PME qui confient des travaux de recherche et développement d'une durée maximale de douze mois à une université ou à un institut de recherche.
• IBI-EFRE. Subvention pour les investissements par lesquels des PME commerciales mettent en œuvre la numérisation dans la production et les modèles d'affaires. Certains secteurs sont exclus, un volume minimal d'investissement s'applique, et la demande est déposée via le portail de l'ISB avant le début du projet. Fiche dans la Förderdatenbank.
• Betriebsberatungsprogramm RLP. Subvention pour du conseil externe, y compris explicitement sur la numérisation et l'intelligence artificielle. Les demandes sont possibles depuis le 16 décembre 2025, et certains thèmes exigent une recommandation de la chambre consulaire. Le programme remplace le conseil technologique BITT, arrêté fin 2025. Page du programme de l'ISB.

La vue d'ensemble des programmes d'innovation et de numérisation se trouve sur isb.rlp.de. Dans le catalogue européen pour l'Allemagne, aucun EDIH ayant son siège en Rhénanie-Palatinat n'a pu être trouvé (situation en septembre 2026). Les options les plus proches sont l'EDIH Saarland, qui s'adresse aussi à la Grande Région, et le Mittelstand-Digital Zentrum Kaiserslautern, qui accompagne les entreprises de Rhénanie-Palatinat sur la maturité IA.

Les programmes régionaux en Rhénanie-du-Nord-Westphalie

En Rhénanie-du-Nord-Westphalie, Mittelstand Innovativ & Digital (MID) est la voie d'accès centrale pour les PME établies dans le Land, et depuis le 1er janvier 2026 c'est la NRW.BANK qui approuve les nouveaux projets.

• MID-Digitalisierung. Subvention pour le développement de produits numériques orientés marché reposant sur des technologies clés, y compris explicitement l'IA, l'apprentissage automatique et le data mining. Page produit de la NRW.BANK.
• MID-Digitale Sicherheit. Subvention pour des analyses de l'état informatique, tests d'intrusion compris, la formation du personnel et des mesures de protection informatique de base. Portail des aides de NRW.

Les deux programmes attribuent les places de dépôt par un tirage au sort mensuel. Les entreprises tirées au sort disposent de 28 jours pour déposer leur demande, et le tirage ne vaut pas encore engagement de financement. L'appel 2026 de MID-Digitale Prozesse, qui finance le conseil externe, est déjà clos, le nombre maximal de demandes ayant été atteint (situation en septembre 2026). La Rhénanie-du-Nord-Westphalie compte en outre trois EDIH : à Dortmund, en Rhénanie avec siège à Aix-la-Chapelle, et en Westphalie du Sud.

Autres Länder et programmes arrivés à échéance

Pour tous les autres Länder, la Förderdatenbank (base de données fédérale des aides) est le moyen le plus rapide de trouver les programmes adaptés. Chaque Land a ses propres programmes, et la Förderdatenbank recense les aides du niveau fédéral, des Länder et de l'UE, filtrables par région, bénéficiaires et type d'aide. La page de l'organisme financeur reste déterminante, car les appels ouvrent et ferment au cours de l'année.

Deux programmes fédéraux encore souvent recherchés sont arrivés à échéance : Digital Jetzt n'accepte plus de demandes, et go-digital a été arrêté fin 2024. L'appellation ERP-Digitalisierungs- und Innovationskredit est elle aussi dépassée, le produit actuel de la KfW étant l'ERP-Förderkredit Digitalisierung.

Étape par étape jusqu'à la demande

Pour presque tous les programmes, le chemin jusqu'à la demande suit les mêmes dix étapes, même si les formulaires et les portails diffèrent.

1. Vérifier le statut de PME. Selon la recommandation européenne 2003/361, est une PME l'entreprise qui compte moins de 250 salariés et respecte les seuils de chiffre d'affaires annuel ou de total du bilan. Les entreprises partenaires et liées peuvent être prises en compte. La Forschungszulage et l'ERP-Förderkredit Digitalisierung sont également ouverts aux entreprises plus grandes. Définition européenne des PME.
2. Profiter d'une orientation gratuite. Un Mittelstand-Digital Zentrum, un EDIH ou le service fédéral de conseil en financement vous aident à situer le projet avant d'investir des efforts dans une demande.
3. Vérifier le programme et son statut. Le programme est-il ouvert, y a-t-il une date limite, un tirage au sort ou un arrêt des demandes ?
4. Ne pas commencer avant l'accord. Un démarrage anticipé de la mesure (vorzeitiger Maßnahmenbeginn), c'est-à-dire un démarrage avant réception de la décision d'octroi, n'est en règle générale pas autorisé, sauf si la directive ou un accord écrit le permet. Cela vaut aussi pour les commandes fermes passées à des prestataires. Pour la KfW, la demande doit être déposée avant le début du projet.
5. Additionner les aides de minimis. Lorsqu'un programme accorde des aides de minimis, un plafond de 300 000 euros par entreprise sur trois ans s'applique. Dans la demande, vous déclarez ce que vous avez déjà reçu sur cette période. Depuis le 1er janvier 2026, un registre central est obligatoire à cet effet. Règlement (UE) 2023/2831.
6. Rédiger l'esquisse de projet. Dans les procédures en deux étapes, tout commence par une courte esquisse qui doit être compréhensible sans questions complémentaires et qui est en concurrence avec d'autres esquisses. Les projets sont suivis par des Projektträger (organismes de gestion de projets) tels que DLR, PtJ ou VDI/VDE-IT, qui agissent pour le compte du ministère. Notions de base du financement de projets.
7. Déposer la demande. Les demandes de recherche fédérales passent le plus souvent par easy-Online, les prêts KfW par votre banque, les programmes régionaux par les portails de l'ISB ou de la NRW.BANK. Les pièces habituelles sont une description du projet avec plan de travail, un plan de coûts et de financement, des documents de solvabilité, la déclaration de PME, le cas échéant la déclaration de minimis, et des devis de fournisseurs.
8. Assurer l'apport propre. Les subventions ne couvrent qu'une partie des coûts, et l'entreprise finance elle-même le reste.
9. Vérifier le cumul. Les aides peuvent être combinées, mais uniquement dans la limite des intensités d'aide autorisées, et les mêmes coûts ne peuvent jamais être financés deux fois. L'usage est de répartir par poste de coûts, par exemple un conseil gratuit, un prêt pour l'investissement et la Forschungszulage pour la part de développement.
10. Rendre compte et fournir le justificatif d'emploi des fonds. Pendant le projet, vous rendez compte au Projektträger, et à la fin vient le Verwendungsnachweis, composé d'un état chiffré et d'un rapport technique final. FAQ du DLR Projektträger.

Erreurs typiques

Les erreurs typiques sont d'ordre formel et peuvent être évitées avant la demande.

• Commander trop tôt. Signer de manière ferme des contrats de fourniture ou de conseil avant l'accord, voire avant la demande selon le programme, peut faire perdre l'éligibilité.
• Surestimer le statut de PME. La filiale d'un groupe plus important n'est pas forcément une PME, même si elle est elle-même petite.
• Ne pas vérifier le statut. Des programmes ferment aussi en cours d'année, comme le montrent l'arrêt des demandes ZIM et l'appel complet de MID-Digitale Prozesse en 2026.
• Mal comprendre le tirage au sort. Pour MID, être tiré au sort n'est pas un engagement, et le délai qui suit est court.
• Manquer l'objet du programme. Un programme de conseil ne finance pas de licences logicielles, et un Mittelstand-Digital Zentrum ne verse pas d'argent.
• Manquer la date limite. Pour KMU-innovativ, une date limite manquée signifie six mois d'attente.
• Mal calculer le de minimis. La période de trois ans est glissante et non liée aux années civiles.
• Confondre les noms. L'EDIH Rheinland est établi à Aix-la-Chapelle et n'est pas un interlocuteur pour la Rhénanie-Palatinat. Des articles de blog plus anciens citent en outre des programmes et des noms de produits qui n'existent plus.

Quel programme pour quel projet d'IA

Le programme adapté découle de la nature du projet : recherche, adoption ou conseil.

Un projet d'IA est proche de la recherche lorsqu'il comporte un risque technique, par exemple une nouvelle méthode ou un modèle pour une question dont le résultat n'est pas connu d'avance. C'est à cela que sont destinés la Forschungszulage, KMU-innovativ, InnoTop et l'Innovationsgutschein, ZIM après sa réouverture, et l'EIC Accelerator pour les projets de rupture proches du marché.

Il s'agit d'adoption lorsqu'une technologie éprouvée est introduite dans votre propre entreprise, par exemple une recherche dans vos propres documents ou l'automatisation d'un processus. Conviennent alors l'ERP-Förderkredit Digitalisierung, IBI-EFRE en Rhénanie-Palatinat et MID-Digitalisierung en Rhénanie-du-Nord-Westphalie si un produit numérique en résulte. Les appels ouverts du financement en cascade peuvent porter de petits projets pilotes.

Le conseil vient en premier lorsqu'il reste à savoir si un cas d'usage tient. Les Mittelstand-Digital Zentren et les EDIH sont gratuits, et le conseil externe est subventionné en Rhénanie-Palatinat par le Betriebsberatungsprogramm. Pour la sécurité informatique autour d'un projet d'IA, la Rhénanie-du-Nord-Westphalie propose MID-Digitale Sicherheit.

Cet article constitue une information générale et non un conseil juridique ou fiscal, et les conditions de financement évoluent.

Un projet d'IA devrait être cadré avant que la question du financement ne soit posée, plus d'informations sous maturité IA.

Ce qu'est Slush

Slush est une conférence pour start-up et investisseurs à Helsinki, née en 2008 d'un rassemblement de 250 personnes. Elle est à but non lucratif, appartient à la Startup Foundation finlandaise et est organisée par des étudiants et de jeunes diplômés avec une grande équipe de bénévoles.

L'événement a lieu les 18 et 19 novembre 2026 au Helsinki Expo and Convention Centre (Messukeskus), avec un programme Day 0 le 17 novembre. Selon l'organisateur, plus de 12 000 personnes y participent, dont environ trois quarts de start-up ou d'investisseurs. L'accent est mis sur des start-up européennes sélectionnées, des investisseurs internationaux et des médias tech, et Slush cite explicitement la région DACH comme région clé. Le programme et les détails figurent sur le site officiel de Slush.

Ce qu'apporte iiterate

iiterate apporte à Helsinki le travail que nous faisons au quotidien : l'IA pour des environnements dans lesquels les données ne doivent pas quitter l'entreprise. Nous sommes un cabinet de conseil en IA basé à Adenau, en Rhénanie-Palatinat, et nous nous rendons à Helsinki au sein de la délégation allemande. Nos domaines :

• LLM on-premise. Des modèles de langage qui fonctionnent sur votre propre infrastructure.
• RAG et gestion des connaissances. Des systèmes de retrieval qui tirent les réponses des documents d'une entreprise et en citent les sources.
• IA avec hébergement des données dans l'UE. Des architectures dans lesquelles le traitement et le stockage restent dans l'Union européenne.
• Computational design. Des modèles paramétriques et des configurateurs dans lesquels des règles génèrent la géométrie.

Dans nos échanges, nous partons de questions concrètes : quelles données un projet concerne, où le traitement peut avoir lieu et quelle architecture en découle.

Qui devrait nous rencontrer

Ce sont avant tout les investisseurs, les entreprises ainsi que les fondatrices et fondateurs confrontés à l'IA et aux données sensibles qui devraient nous rencontrer.

• Les investisseuses et investisseurs qui évaluent des projets d'IA dans des secteurs réglementés ou sensibles en matière de données.
• Les entreprises qui souhaitent utiliser l'IA sur des documents confidentiels et ont besoin pour cela d'un hébergement des données dans l'UE ou dans leurs propres locaux.
• Les fondatrices et fondateurs qui travaillent sur l'IA avec des données sensibles et souhaitent échanger sur l'architecture, l'exploitation ou une collaboration.

Un projet qui n'est pas encore entièrement réfléchi n'est pas un obstacle, mais un bon point de départ pour un échange.

Convenir d'un rendez-vous à Helsinki

Le mieux est de convenir d'un rendez-vous à Helsinki à l'avance via notre page de contact. Indiquez brièvement votre sujet et les jours où vous serez sur place. Les échanges peuvent se tenir en allemand ou en anglais.

La spécification, sans le marketing

Avant de parler de conséquences, le tableau sobre aide. Toutes les valeurs proviennent de l'aperçu des modèles et de la page tarifaire d'Anthropic, consultés le 10 septembre 2026.

Ce qu'Anthropic ajoute dans son propre aperçu des modèles mérite d'être noté : Claude Opus 5 est recommandé comme choix par défaut pour la plupart des charges de travail, et Fable 5.1 est prévu pour les cas où Opus 5 à un niveau d'effort supérieur ne suffit pas. C'est une autolimitation inhabituellement nette, et c'est aussi le premier filtre de toute décision d'architecture. Fable 5.1 n'est pas une montée en gamme générale, mais un outil pour des tâches longues et continues.

La modalité est étroite, et cela compte en pratique. Le texte et les images entrent, le texte sort. Pas d'audio en entrée, pas d'audio en sortie, aucune génération d'image ou de vidéo. Pour traiter l'enregistrement d'un appel, il faut une transcription en amont. Pour obtenir des réponses parlées, il faut une synthèse vocale en aval. Pour produire des visuels, il faut un autre modèle. Cela paraît anodin, mais cela déplace les frontières du système, les coûts et les questions de protection des données exactement là où se trouvent ces composants supplémentaires.

Ce qu'un million de tokens change, et ce qu'il ne change pas

La fenêtre est facturée aux tarifs normaux par token sur toute sa longueur, sans supplément pour contexte long (Anthropic). Cela rend possibles des montages qui échouaient auparavant non pas sur le modèle mais sur le découpage : un corpus complet de contrats ou d'appels d'offres en une seule passe plutôt qu'en trente fragments suivis d'une fusion ; une trace d'agent entière, sorties d'outils comprises, qui reste analysable au lieu d'être coupée après vingt étapes ; un dépôt de taille moyenne sur lequel une question trouve réponse d'un seul tenant plutôt que via une recherche qui doit deviner à l'avance quels fichiers comptent. Le gain tient moins à l'intelligence qu'à la disparition de toute une catégorie de travail de raccordement, et dans nos projets ce travail de raccordement était régulièrement la source des erreurs difficiles à trouver.

Le chiffre n'est pourtant pas un nombre de pages. Anthropic évalue 1 000 000 de tokens à environ 555 000 mots anglais avec le tokeniseur actuel, et précise dans le même mouvement que ce tokeniseur produit environ 30 pour cent de tokens de plus pour le même texte que le précédent (Anthropic). Cette indication porte sur du texte anglais ; aucun chiffre pour un corpus germanophone ne peut en être déduit, il faut le mesurer. Qui planifie de la capacité compte ses propres documents avec le tokeniseur du modèle qu'il utilise réellement, et ne raisonne pas en pages.

Pour la même raison, comparer des tailles de fenêtre entre fournisseurs ne dit rien. Un token est une unité propre au fournisseur, et aucune conversion publiée ne ramène deux tokeniseurs à la même quantité de texte. Un nombre sur une fiche technique n'indique donc pas quel modèle contient le plus de votre texte.

Et la fenêtre plus grande ne rend pas la recherche documentaire inutile. Le raisonnement est simple : tout ce qui se trouve dans la fenêtre est payé à chaque appel et doit être traité à chaque appel. Une méthode qui trouve les vingt paragraphes pertinents reste plus rapide, moins coûteuse et généralement plus précise qu'une méthode qui y verse dix mille paragraphes en espérant l'attention. La grande fenêtre repousse nettement le seuil à partir duquel le découpage devient nécessaire. Elle ne remplace pas la question de savoir quelle information est nécessaire pour cette réponse précise.

La véritable histoire d'ingénierie s'appelle lecture de cache

Le chiffre le plus intéressant de la spécification n'est pas une valeur absolue mais un rapport. Une entrée nouvelle coûte 10 USD par million de tokens, un succès de cache 0,25 USD. L'écriture en cache coûte 12,50 USD par million de tokens au palier de cinq minutes et 20 USD au palier d'une heure. Sur Fable 5.1 et Mythos 5.1, le prix de lecture est de 0,025 fois le prix de base, contre 0,1 fois sur tous les autres modèles Claude, et c'est selon Anthropic la seule modification tarifaire par rapport à Fable 5 (Anthropic).

Le facteur 40 entre entrée nouvelle et succès de cache est ce qui décide des conceptions. Dans une boucle d'agent, le même prompt système, les mêmes définitions d'outils et le même contexte de projet sont relus à chaque étape. Une tâche de deux cents appels d'outils relit deux cents fois le même préambule. Que ce préambule soit facturé chaque fois comme entrée nouvelle ou comme succès de cache n'est pas un détail comptable, mais la frontière entre une conception que l'on peut mettre en production et une conception que l'on laisse en démonstration.

C'est précisément pour cela que la formulation d'Anthropic, selon laquelle les charges de travail typiques seraient environ 25 pour cent moins chères et les charges fortement agentiques jusqu'à environ 45 pour cent, est une estimation portant sur des taux de succès de cache et non une baisse de prix (Anthropic). Les prix affichés d'entrée et de sortie sont inchangés par rapport à Fable 5. Une charge de travail à faible localité de cache ne voit presque rien de cette économie, et inscrire les 25 pour cent dans un budget sans cette réserve produit un espoir, pas un budget.

Ce qui rend les taux de succès bons ou mauvais en pratique n'est pas une métrique documentée mais une logique d'ingénierie, et elle se nomme :

• Un préfixe stable. Ce qui est réutilisé, c'est le début inchangé de la requête. Tout ce qui est constant va devant, tout ce qui varie derrière. Un horodatage, un identifiant de session ou un nom d'utilisateur mal placé invalide tout le contexte qui suit.
• Un assemblage déterministe. Des listes d'outils en ordre aléatoire, des résultats de recherche au tri changeant ou des objets à ordre de clés instable produisent un nouveau préfixe à chaque exécution. Le cache ne voit alors jamais deux fois la même chose.
• La durée de vie face au rythme de la tâche. Cinq minutes conviennent à une boucle d'agent cadencée serré. Elles ne conviennent pas à un dialogue où une personne passe vingt minutes en réunion entre deux questions. Le palier d'une heure coûte plus cher à l'écriture et ne devient rentable que lorsqu'il sauve effectivement le succès.
• Assez de répétition par préfixe. Beaucoup de requêtes courtes et sans lien entre elles se répartissent sur de nombreux préfixes. Chacune paie une écriture et obtient rarement une lecture. C'est le cas où l'économie du cache joue contre vous, et l'interface par lots avec 50 pour cent de remise dans les deux sens est alors souvent la meilleure voie.

Un repère concret de la grille tarifaire appuie le même point : la trousse d'outils pour l'usage de l'ordinateur ajoute environ 4 500 tokens d'entrée par requête, celle pour l'usage du navigateur environ 6 600 (Anthropic). C'est un bloc constant qui revient à chaque étape, donc exactement la matière qui a sa place dans un préfixe stable.

Fonctionnement agentique, outils et la question du niveau d'effort

Fable 5.1 est conçu pour des exécutions longues. Anthropic cite comme preuve une exécution non supervisée de 38 heures sur un problème d'apprentissage automatique (Anthropic). C'est une déclaration de fournisseur sur une exécution unique et non un résultat de distribution, mais cela vaut comme ordre de grandeur de ce vers quoi le modèle a été conçu.

Le mode de réflexion est adaptatif et toujours actif ; l'ancien mode manuel avec budget de réflexion explicite n'est plus accepté. Par rapport à Fable 5, il y a trois changements de rupture qui touchent toute intégration existante : l'usage forcé d'outils renvoie une erreur, les modèles antérieurs ne peuvent pas lire les blocs de réflexion de ce modèle, et modifier des tours antérieurs invalide ces blocs. S'y ajoutent notamment un niveau d'effort par message, des messages système valables au tour, des rapports d'avancement lisibles entre les appels d'outils ainsi que le prix de lecture de cache réduit ; plusieurs sont marqués comme bêta (Anthropic). Pour la planification, cela signifie qu'un passage à ce modèle n'est pas un changement de configuration, mais une petite reconstruction suivie d'un test.

Les niveaux d'effort demandent de la rigueur. La documentation indique high comme valeur par défaut (Anthropic), et l'annonce précise que ce réglage diffère selon la surface : high dans Claude Code, medium dans Claude Cowork et sur claude.ai (Anthropic). L'ensemble complet des valeurs acceptées ne figure pas sur les pages de documentation que nous avons consultées, et nous ne l'affirmons donc pas.

La conséquence pratique est inconfortable mais importante : un chiffre de benchmark ou une estimation de coût sans niveau d'effort indiqué n'est pas reproductible. Deux équipes qui mesurent le même modèle par deux surfaces différentes mesurent des configurations différentes. Qui veut que ses propositions, ses résultats de test ou ses comparaisons internes tiennent note le niveau à côté du chiffre, comme on ne laisserait pas passer une mesure sans son unité.

Une date de connaissance en juin 2026 est une exigence d'architecture

La date de connaissance et des données d'entraînement est juin 2026 (Anthropic). Sur le plan opérationnel, cela ne signifie rien de dramatique et beaucoup à la fois. Votre grille tarifaire de la semaine dernière, la décision d'hier, l'état de votre carnet de commandes ce matin : rien de tout cela n'est dans le modèle. Cela doit entrer dans le contexte par la recherche documentaire, par une connexion d'outil ou par le prompt.

Ce n'est pas un défaut du modèle mais une exigence pour l'architecture, et elle est indépendante du fournisseur. Tout système censé renseigner sur des faits actuels sans chemin défini par lequel ces faits arrivent est mal spécifié, aussi bon soit le modèle. Deux conséquences nous ont bien servi. D'abord, toute réponse fondée sur des faits appelle une source nommable dans le contexte, et non la mémoire du modèle. Ensuite, tout jeu d'évaluation doit contenir quelques questions dont la bonne réponse a changé après la date de connaissance : elles testent précisément le chemin qui, en production, se rompt le plus volontiers en silence.

Le filigrane de l'article 50 n'est pas une piste d'audit

Fable 5.1 et Mythos 5.1 portent dès le lancement un filigrane textuel invisible (Anthropic). Anthropic applique ce marquage dans le monde entier et pas seulement dans l'UE (Euronews). Le contexte est l'obligation de transparence de l'article 50 du règlement sur l'IA, applicable depuis le 2 août 2026, qui exige un marquage lisible par machine des contenus synthétiques.

L'essentiel tient à la réserve qu'Anthropic formule elle-même. Un filigrane détecté indique qu'un contenu a peut-être été traité par Claude, n'est expressément pas pleinement concluant et ne confirme pas à lui seul la provenance du contenu (Anthropic Help Center). S'y ajoute que l'interface de détection n'est ouverte qu'à un cercle restreint dans un aperçu privé (MacRumors).

Pour une entreprise qui veut documenter son propre usage de l'IA, il en découle une contrainte de conception sobre, et il s'agit d'une appréciation technique et non d'un conseil juridique : le filigrane est un signal dans la sortie qui ne vous appartient pas, que vous ne pouvez généralement pas lire vous-même et dont le fournisseur limite lui-même la portée probante. Ce n'est donc pas une piste d'audit. S'il doit être traçable quel modèle a produit quelle sortie à partir de quelle entrée et à quel moment, et qui l'a validée, cette preuve naît dans vos propres enregistrements. Techniquement c'est peu spectaculaire, car ce sont les mêmes journaux que l'on tient de toute façon pour le débogage et le contrôle des coûts.

La contrainte qui décide de l'architecture en Allemagne

Dans les projets allemands, c'est plus souvent le traitement des données que la capacité qui décide de l'emploi d'un modèle. Ici la situation est clairement documentée et surprend beaucoup de monde. Anthropic classe Fable 5.1 comme Covered Model. Ces modèles supposent une conservation des données de 30 jours et ne sont pas disponibles sous conservation nulle des données, sauf autorisation expresse d'Anthropic. Une organisation qui fonctionne en conservation nulle doit activer délibérément la conservation pour un espace de travail déterminé, faute de quoi les requêtes sont rejetées avec une erreur (Anthropic).

Deux compléments de la même source s'imposent, sans quoi le tableau serait faussé. Les données conservées ne sont pas, selon Anthropic, utilisées pour l'entraînement des modèles sans autorisation expresse. Et même en conservation nulle, un contenu signalé peut être conservé jusqu'à deux ans. La conservation nulle ne couvre pas non plus toutes les voies d'accès au système, notamment ni l'interface par lots ni le stockage de fichiers.

S'y ajoute la question de la région. Sur l'interface de première partie, il n'existe pas de région d'inférence dans l'UE. Le paramètre de région d'inférence accepte exactement deux valeurs, global et us, et le stockage se fait exclusivement aux États-Unis ; la région d'un espace de travail n'est plus modifiable après sa création (Anthropic). La voie praticable dans l'UE passe par un cloud partenaire : Amazon Bedrock et Google Cloud proposent des points de terminaison régionaux avec acheminement garanti des données, moyennant un supplément de 10 pour cent par rapport aux points de terminaison globaux, et fixent leurs propres dates de cycle de vie (Anthropic).

C'est une donnée de conception et non un verdict sur le modèle. Trois voies subsistent en pratique, et le choix se fait avant le premier prototype, pas après. Premièrement : un point de terminaison régional chez un cloud partenaire, avec le supplément et avec le fournisseur de cloud comme sous-traitant. Deuxièmement : l'interface de première partie avec conservation délibérément activée, pour les catégories de données où cela se défend. Troisièmement : la catégorie de données concernée n'atteint jamais ce modèle, parce qu'un autre modèle ou une exploitation locale prend en charge la partie qui voit les champs sensibles. La troisième voie est trop rarement examinée, alors qu'elle est souvent la plus propre dans les systèmes de connaissance et de documents.

Ce qui change, et ce que ce modèle ne touche pas

Nommé honnêtement, un ensemble limité mais précieux de catégories de tâches change. Les analyses sur des corpus qui échouaient jusqu'ici sur le découpage deviennent faisables en une passe. Les exécutions d'agents qui se disloquaient à la limite du contexte restent continues. Et les conceptions qui doivent relire très souvent la même base deviennent économiquement viables grâce au prix de lecture de cache, à condition que l'assemblage produise le taux de succès. Ce sont trois déplacements réels, et ils touchent exactement le travail qui, en conseil, arrive autrement sous forme de besogne.

Nommé tout aussi honnêtement, ce qui reste inchangé. Les capacités du modèle sont elles aussi bornées : tests d'intrusion, génération d'exploits, analyse à partir de binaires et travaux de recherche en biologie sont renvoyés vers les modèles Opus, et le mode rapide n'est pas disponible sur Fable 5.1 (Anthropic, Anthropic).

Plus importants encore sont les problèmes qu'aucun modèle ne touche. La qualité des données reste votre affaire : une fenêtre plus grande lit seulement plus soigneusement des données de référence contradictoires. La définition des processus reste votre affaire : un agent qui ignore quand une question est tranchée ne fait que reproduire le flou qui régnait déjà dans l'équipe. Les droits d'accès restent votre affaire : un modèle autorisé à tout voir est un problème de protection des données doué pour la langue. L'évaluation reste votre affaire, car sans un jeu de cas à réponses connues personne ne peut dire si un changement a amélioré quoi que ce soit. Et le coût de l'erreur reste où il était : sur une liste de suggestions une erreur est agaçante, sur une facture sortante elle coûte cher. Cette distinction décide du degré d'automatisation, et c'est une question de gestion.

Notre position est sans emphase : Fable 5.1 déplace la limite de ce qu'un montage peut porter, et il la déplace à un endroit qui freinait réellement en pratique. Il ne déplace aucune des questions qui doivent être réglées avant. Laquelle de ces questions reste ouverte dans votre prochain projet ?

Cet article lit la publication comme devrait la lire une entreprise en train de décider si elle va construire dessus : quelles spécifications comptent réellement, ce qui est réel dans la structure tarifaire et ce qui relève d'une estimation modélisée, ce qui casse au niveau de l'interface, et pourquoi la voie européenne vers ce modèle passe par un cloud partenaire et non par Anthropic.

Ce qui a réellement été publié le 1er septembre

Anthropic a publié Claude Fable 5.1 le 1er septembre 2026, en même temps que Claude Mythos 5.1. Selon la présentation d'Anthropic, les deux sont le même modèle avec des niveaux de garde-fous différents : Fable 5.1 est disponible pour tous, Mythos 5.1 uniquement sur invitation via des programmes d'accès de confiance. La presse spécialisée confirme la date et la disponibilité sur toutes les plateformes dès le jour de la sortie.

L'identifiant du modèle est claude-fable-5-1, et anthropic.claude-fable-5-1 sur Amazon Bedrock. Il est livré via l'API Claude, Amazon Bedrock, Google Cloud, Microsoft Foundry et Claude Platform sur AWS. Anthropic cite Claude Code, Claude Enterprise et Claude Platform comme surfaces, avec des niveaux d'effort par défaut différents : high dans Claude Code, medium dans Claude Cowork et sur claude.ai. Un engagement de retrait existe : sur les plateformes exploitées par Anthropic, le modèle ne sera pas arrêté avant le 1er septembre 2027, tandis que Bedrock et Google Cloud fixent leurs propres dates.

Ce qu'Anthropic ajoute dans la même documentation mérite attention. Fable 5.1 est décrit comme destiné au raisonnement exigeant et au travail agentique de longue haleine ; comme choix par défaut pour la plupart des charges de travail, Anthropic recommande toujours explicitement Claude Opus 5, et réserve Fable 5.1 aux cas où Opus 5 à effort élevé ne suffit pas. Qui doit justifier le changement en interne devrait connaître cette phrase : le fournisseur lui-même ne recommande pas son nouveau modèle phare de manière générale.

Les spécifications qui portent une décision

Les chiffres clés proviennent de la documentation modèle d'Anthropic et comptent davantage, pour une décision d'architecture, que n'importe quel classement.

Deux points méritent plus qu'une ligne de tableau. D'abord le mode de réflexion : Fable 5.1 réfléchit de façon adaptative et permanente, et l'ancien mode manuel avec thinking.type: enabled et budget_tokens n'est plus accepté. Qui porte une intégration existante devra toucher à cet endroit du code.

Ensuite la fenêtre de contexte. Un million de tokens correspond, selon Anthropic, à environ 555 000 mots anglais, mesurés avec le tokenizer actuel introduit avec Claude Opus 4.7. Ce même tokenizer produit environ 30 % de tokens en plus pour un texte identique par rapport au précédent. Un chiffre de fenêtre de contexte n'est donc pas une indication de capacité comparable à la légère entre générations de modèles, encore moins entre fournisseurs. Pour la planification budgétaire, ce qui compte est le nombre de tokens que produit réellement votre propre corpus, pas le chiffre affiché.

Cet article s'en tient volontairement à peu de résultats de performance, car ils font l'objet d'un article de comparaison distinct. Seulement ceci, et explicitement en tant que chiffres du fournisseur : Anthropic rapporte pour Fable 5.1 52,6 % sur Terminal-Bench-Science 0.1 contre 24,7 % pour Fable 5, et 55,8 % sur Terminal-Bench 4.0 contre 42,0 %. La colonne de comparaison du tableau d'Anthropic est GPT-5.6 Sol. Le modèle phare actuel d'OpenAI, GPT-6 Astra, est sorti deux jours après cette publication et n'apparaît pas dans les chiffres d'Anthropic.

Le prix : une seule ligne a changé

La documentation tarifaire d'Anthropic indique les valeurs suivantes pour Fable 5.1, en dollars américains par million de tokens.

Une seule ligne est intéressante. Sur Fable 5.1 et Mythos 5.1, les lectures de cache sont facturées à 0,025 fois le prix d'entrée, alors que tout autre modèle Claude applique un facteur de 0,1. C'est le seul changement tarifaire par rapport à Fable 5, dont la lecture de cache s'établissait à 1,00 dollar américain par million de tokens. Entrée et sortie sont inchangées. La fenêtre de contexte complète est facturée aux tarifs normaux par token ; il n'existe pas de supplément pour contexte long.

Anthropic chiffre l'économie à environ 25 % par rapport à Fable 5 pour des charges de travail typiques, et jusqu'à environ 45 % pour un travail fortement agentique. Ce chiffre est assez important pour être lu correctement : il s'agit d'une estimation modélisée du fournisseur, issue entièrement de la ligne de cache, et non d'une baisse de prix. Si vos requêtes relisent rarement le même contexte, vous n'économisez rien. Si vous exploitez une boucle agentique qui relit cent fois le même prompt système, la même base de code et les mêmes définitions d'outils, vous économisez beaucoup. La différence entre ces deux cas tient à votre taux de succès de cache, que seul votre propre profil de charge connaît.

Un détail supplémentaire pour le calcul des coûts : si l'inférence est fixée aux États-Unis via inference_geo: "us", un facteur de 1,1 s'applique à l'entrée, à la sortie, à l'écriture et à la lecture de cache.

Dans le paysage concurrentiel, cette ligne de cache est la seule véritable différence de prix au sommet. OpenAI affiche également 10 et 50 dollars américains par million de tokens en entrée et en sortie pour gpt-6-astra, mais 1,00 dollar pour les entrées mises en cache. Sur les lectures de cache, Fable 5.1 se situe donc au quart du prix, ce qui peut être décisif dans de longues boucles agentiques. Tout le reste de cette comparaison, y compris la question de savoir quels chiffres de benchmark sont réellement comparables, figure dans l'article dédié.

Ce qui change au niveau de l'interface, et ce qui casse

Comme preuve d'autonomie de longue haleine, Anthropic cite une exécution non supervisée de 38 heures sur un problème d'apprentissage automatique. Qui veut construire là-dessus devrait d'abord lire la liste des changements d'interface, car trois d'entre eux cassent du code existant.

Changements cassants par rapport à Fable 5 :

• L'usage forcé d'outils renvoie une erreur.
• Les modèles antérieurs ne peuvent pas lire les blocs de réflexion de Fable 5.1.
• Modifier des tours de conversation antérieurs invalide les blocs de réflexion.

Ajouts :

• Niveau d'effort par message (bêta).
• Messages système limités à un seul tour (bêta).
• Mises à jour de progression lisibles entre les appels d'outils via display: "updates" (bêta).
• Le prix réduit des lectures de cache.
• Le marquage de provenance des contenus.

Pour les architectures agentiques, le surcoût en tokens des jeux d'outils compte également : computer_toolset_20260801 ajoute environ 4 500 tokens d'entrée par requête, browser_toolset_20260801 environ 6 600. C'est une charge de base qui s'applique à chaque requête et qui a sa place dans toute estimation de coût. Le mode rapide, qui existe en aperçu de recherche sur Claude Opus 5 et Opus 4.8, n'est pas disponible pour Fable 5.1.

Côté sécurité, Anthropic indique que les garde-fous en cybersécurité bloquent 60 % de faux positifs en moins qu'auparavant, et que les garde-fous en biologie se déclenchent 85 % moins souvent pour des demandes bénignes relevant de la biologie élémentaire. Dans le même temps, des classes entières de tâches restent exclues : tests d'intrusion, génération d'exploits, analyse binaire et travaux de recherche en biologie sont redirigés vers les modèles Opus. Fable 5.1 peut identifier des vulnérabilités logicielles, la génération d'exploits restant bloquée. Les nouveaux comptes API ne peuvent en outre plus modifier manuellement le contexte antérieur dans des conversations à plusieurs tours ; Anthropic justifie cela par le fait que cela ferme une technique de distillation courante et publiquement documentée. Pour les équipes qui réécrivent des historiques de conversation par programme, il s'agit d'un changement de comportement aux conséquences directes sur les architectures existantes.

Résidence des données : il n'existe pas de région UE chez Anthropic

C'est ici que l'histoire technique se sépare de l'histoire de gouvernance. La documentation d'Anthropic sur la résidence des données est sans ambiguïté : le paramètre inference_geo accepte exactement deux valeurs, global et us. Sous les limitations actuelles, il est écrit noir sur blanc que seules ces deux valeurs sont disponibles. Il n'existe pas de région d'inférence UE sur l'API propriétaire d'Anthropic.

Il en va de même pour les données au repos. La région d'un workspace est fixée à sa création, ne peut plus être modifiée ensuite, et la seule valeur disponible sont les États-Unis.

Deux sources d'Anthropic semblent ici se contredire, et cela mérite d'être dit ouvertement. Le centre d'aide sur la confidentialité, mis à jour le 15 juin 2026, indique que le trafic client peut par défaut être acheminé vers certains pays aux États-Unis, en Europe, en Asie et en Australie, et ajoute dans le même texte que les données sont stockées aux États-Unis. La documentation de la plateforme, elle, ne connaît que les deux régions d'inférence citées. La réconciliation tient à la distinction entre acheminement et résidence : le mode global peut transiter par l'Europe, mais il ne constitue pas une garantie sélectionnable que le traitement et le stockage aient lieu dans l'UE. Qui a besoin d'une telle garantie ne la trouvera pas ici.

Le paramètre inference_geo n'existe par ailleurs qu'à partir de Claude 4.6 ; les modèles antérieurs renvoient une erreur 400. Il n'existe pas sur Amazon Bedrock ni sur Google Cloud, où le point de terminaison ou le profil d'inférence détermine la région. Microsoft Foundry propose à la place un type de déploiement en zone de données américaine. Le paramètre n'est pas non plus disponible via le point de terminaison compatible avec le SDK OpenAI.

La voie européenne praticable ne passe donc pas par Anthropic mais par un cloud partenaire. Bedrock et Google Cloud proposent des points de terminaison régionaux avec acheminement garanti des données, moyennant un supplément de 10 % par rapport aux points de terminaison globaux selon la documentation tarifaire d'Anthropic, et fixent leurs propres dates de cycle de vie. Cela rend également l'affirmation répandue selon laquelle Claude bénéficierait d'une résidence des données dans l'UE parce qu'il tourne à Francfort à moitié vraie et, au final, trompeuse : les modèles Claude peuvent tourner dans des régions UE, mais c'est alors le fournisseur cloud qui est sous-traitant du traitement, et non Anthropic. Pour le montage contractuel, c'est précisément là que se situe la différence.

Covered Model : 30 jours de conservation sont une condition, pas une option

La phrase la plus inconfortable de toute la documentation se trouve sur la page d'Anthropic consacrée à l'API et à la conservation des données. Elle indique, à propos de Claude Fable 5.1, Mythos 5.1, Fable 5 et Mythos 5, que ces modèles exigent une conservation des données de 30 jours et ne sont pas disponibles sous zero data retention sauf autorisation expresse d'Anthropic. Ils sont classés Covered Models.

Concrètement, une organisation qui travaille aujourd'hui sous zero data retention ne peut pas simplement activer Fable 5.1. Elle doit activer explicitement la conservation de 30 jours sur un workspace donné, sans quoi l'API répond par 400 invalid_request_error. Ce n'est pas une subtilité de configuration mais une décision qui, dans bien des maisons, doit passer par la validation du responsable de la protection des données avant que n'existe la première ligne de code d'intégration.

Par souci d'exhaustivité, les engagements d'Anthropic ont leur place à côté : les données conservées ne sont, selon ses propres termes, jamais utilisées pour l'entraînement des modèles sans autorisation expresse, et le contenu des conversations n'est pas conservé par défaut en dehors de l'exception Covered Model.

Même qui dispose déjà du zero data retention devrait en connaître les limites, plus étroites que le nom ne le laisse penser.

• Le ZDR s'active par organisation, sur demande via le service commercial, et ne s'étend pas automatiquement aux organisations sœurs sous le même compte.
• Il ne couvre ni l'API Batch, ni l'API Files, ni l'exécution de code, ni Claude for Excel, ni les interfaces produit Claude Teams et Claude Enterprise. Claude Code via Claude Enterprise avec ZDR constitue l'exception mentionnée.
• CORS n'est pas pris en charge pour les organisations sous ZDR.
• Si une conversation ou une session est signalée, Anthropic peut conserver entrées et sorties jusqu'à deux ans, y compris sous ZDR.

La direction est donc claire, et elle va à l'encontre de l'histoire tarifaire. Fable 5.1 est moins cher en boucle agentique que tout autre modèle Claude, et sous des règles européennes strictes il est en même temps plus difficile à déployer que les modèles Claude qui ne figurent pas sur cette liste.

Article 50 : un filigrane dès le premier jour, avec la réserve d'Anthropic

Selon Anthropic, Fable 5.1 et Mythos 5.1 portent un filigrane textuel invisible dès le jour de la sortie. L'article 50 du règlement européen sur l'IA, qui impose un marquage lisible par machine des contenus synthétiques, s'applique depuis le 2 août 2026. Anthropic applique ce marquage dans le monde entier et pas seulement dans l'UE.

Qui veut intégrer le filigrane dans un processus de contrôle devrait connaître la réserve d'Anthropic elle-même, clairement énoncée dans son centre d'aide : un filigrane détecté indique qu'un contenu a peut-être été traité par Claude, il est "not fully conclusive", autrement dit pas pleinement concluant, et ne confirme pas à lui seul la provenance complète du contenu. Ce n'est donc pas une preuve au sens juridique, et attendre d'en établir la paternité va au-delà de ce que le fournisseur affirme lui-même. La configuration est remarquable : le marquage est une véritable caractéristique du modèle, et sa portée probante est relativisée par l'entreprise même qui le propose.

S'y ajoute la question de l'accès. L'API de détection est en aperçu privé et ouverte aux seules organisations éligibles ; sont cités les autorités de régulation, les forces de l'ordre, les médias, les vérificateurs de faits, la recherche, les établissements d'enseignement et les organisations de la société civile dans l'UE. Une entreprise qui souhaite vérifier elle-même des textes entrants ne peut actuellement pas le faire par cette voie.

Le cadre réglementaire environnant, tel que le décrivent les instances qui le publient : l'application aux modèles d'IA à usage général court elle aussi depuis le 2 août 2026, avec des amendes pouvant atteindre 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial pour les fournisseurs non conformes de tels modèles, qu'ils aient ou non signé le code de bonnes pratiques. Le code de bonnes pratiques de la Commission européenne engage les signataires sur un formulaire de transparence publié, une méthodologie d'évaluation des risques systémiques et un cadre de conformité au droit d'auteur, avec une conservation de la documentation pendant au moins dix ans. Ces obligations pèsent sur les fournisseurs de modèles. Ce qui en découle pour votre propre maison dépend de votre rôle dans la chaîne d'approvisionnement et relève de vos conseils juridiques, pas d'un article professionnel.

Ce que cela signifie pour une décision en Allemagne

Prise dans son ensemble, la publication donne une image inhabituellement claire, précisément parce que les deux histoires pointent dans des directions opposées. Techniquement, Fable 5.1 est le choix le moins cher pour de longues boucles agentiques où le même contexte est relu sans cesse. Sur le plan réglementaire, c'est un modèle qu'on ne peut même pas démarrer sans conservation de 30 jours.

Quatre questions devraient donc être tranchées avant que l'intégration ne commence.

1. Quel est réellement votre taux de succès de cache ? Toute l'économie tient à cette seule mesure. Mesurez-la sur un profil de charge réel avant de budgéter 25 %.
2. Votre validation en protection des données supporte-t-elle une conservation de 30 jours ? Si non, Fable 5.1 n'est pas une option tant qu'Anthropic n'a pas donné son autorisation expresse, et la question ne se contourne pas techniquement.
3. Par quel point de terminaison passe l'inférence ? Si un traitement dans l'UE est requis, la voie passe par Bedrock ou Google Cloud, avec un supplément de 10 % par rapport aux points de terminaison globaux, avec le fournisseur cloud comme sous-traitant et avec ses propres dates de cycle de vie.
4. Opus 5 suffit-il ? Anthropic recommande lui-même Opus 5 par défaut, et Opus 5 ne figure pas sur la liste des Covered Models. Une partie des questions de gouvernance décrites ici ne s'y pose pas sous cette forme.

Rien de tout cela n'est un argument contre Anthropic. Fable 5.1 est un modèle solide, le changement sur le cache est une amélioration réelle pour le travail agentique, et le fait que les données inconfortables soient proprement consultables dans la documentation d'Anthropic plaide pour le fournisseur plutôt que contre lui. C'est un argument pour inverser l'ordre : clarifier d'abord les conditions dans lesquelles vos données peuvent être traitées, puis choisir le modèle. Ce que Fable 5.1 apporte réellement au travail quotidien fait l'objet d'un article dédié aux capacités en pratique ; sa position face à GPT-6 Astra, d'un autre.

Le tableau que presque tout le monde publie est faussé

La phrase la plus fréquente dans la couverture actuelle revient à peu près à ceci : les propres benchmarks d'Anthropic placeraient Claude Fable 5.1 devant GPT-6 Astra. Cette phrase est fausse, et un calendrier suffit à la réfuter.

Anthropic a publié son tableau de benchmarks le 1er septembre 2026. La colonne de comparaison y porte la mention GPT-5.6 Sol. GPT-6 Astra est passé en accès restreint le 3 septembre et en disponibilité générale le 4 septembre. Anthropic n'a donc pas seulement omis de mesurer Astra : l'entreprise ne pouvait pas le mesurer, le modèle n'étant pas public à la date de publication.

Qui lit la ligne Terminal-Bench 4.0, où 55,8 % pour Fable 5.1 s'opposent à 37,3 %, et prend ces 37,3 % pour Astra, compare le modèle actuel d'Anthropic au prédécesseur du concurrent. Ce n'est pas une erreur d'arrondi, c'est un autre énoncé. Et c'est précisément la lecture erronée qui se propage aujourd'hui le plus vite dans les agrégateurs et les résumés.

La valeur de cet article tient donc moins aux chiffres qu'au tri : quelles comparaisons tiennent, lesquelles non, et à quoi se reconnaît la différence.

Ce qui se compare vraiment à l'identique

Il reste un noyau réduit mais propre. Toutes les lignes du tableau ci-dessous proviennent de la documentation modèle d'Anthropic, de la page tarifaire d'Anthropic et de la documentation développeur d'OpenAI sur gpt-6-astra, consultées le 10 septembre 2026. Ce sont les déclarations de chaque fournisseur sur son propre produit, dans la même unité, sans cadre de mesure intermédiaire.

Une réserve s'impose sur la ligne d'écriture de cache : Anthropic vend deux durées de conservation, cinq minutes et une heure, tandis qu'OpenAI ne publie aucun palier équivalent. Les deux montants de 12,50 USD sont proches, mais pas parfaitement parallèles.

La ligne économiquement intéressante est la lecture de cache. Un facteur quatre en faveur d'Anthropic ressemble à un poste secondaire, mais il ne l'est pas dans le travail agentique : le même contexte, dépôt de code, instruction système et descriptions d'outils, y est relu encore et encore sur des centaines d'étapes. Anthropic chiffre lui-même l'économie qui en découle à environ 25 % par rapport à Fable 5 pour des charges typiques et jusqu'à environ 45 % pour des charges fortement agentiques. Ce chiffre est un calcul de modélisation du fournisseur, non une baisse de prix : les tarifs affichés d'entrée et de sortie sont inchangés, et une charge qui produit peu de succès de cache n'économise pratiquement rien.

Deux autres postes appartiennent à tout calcul. L'API Batch d'Anthropic divise les deux sens par deux, soit 5 USD en entrée et 25 USD en sortie par million de jetons. Et fixer l'inférence aux États-Unis chez Anthropic applique, selon la documentation d'Anthropic sur la résidence des données, un multiplicateur de 1,1 sur l'entrée, la sortie, les écritures et les lectures de cache.

Terminal-Bench 4.0 : le seul chiffre doté d'un vrai recoupement

Une ligne de benchmark mérite ici une confiance particulière, pour une raison rarement expliquée.

Le 1er septembre 2026, Anthropic annonce pour Claude Fable 5.1 sur Terminal-Bench 4.0 55,8 %. Dans les résultats rapportés par OpenAI pour GPT-6 Astra, relayés par DataCamp le 3 septembre 2026 et explicitement qualifiés là de chiffres du fournisseur, Astra se situe à 57,7 % et Fable 5.1 est repris à 55,8 %, inchangé.

Les deux fournisseurs aboutissent donc indépendamment au même chiffre pour le modèle du camp adverse. C'est le recoupement le plus solide disponible dans toute cette comparaison. Un fournisseur a peu d'intérêt à surévaluer un concurrent, et lorsque deux parties aux intérêts opposés rapportent le même chiffre, cela plaide pour un chiffre qui survit au dispositif plutôt que pour une mesure maison.

Deux limites subsistent néanmoins. D'abord, aucune des deux publications ne précise le harnais, l'échafaudage ni le niveau d'effort utilisés. Ensuite, l'écart de 1,9 point de pourcentage est assez faible pour provenir exactement de ces facteurs. La lecture défendable est donc la suivante : sur Terminal-Bench 4.0, les deux modèles sont proches selon les indications des deux fournisseurs, avec une légère avance d'Astra selon la mesure d'OpenAI.

Ce qui ne se compare pas, et pourquoi

La plus grande partie des chiffres publiés n'a pas sa place dans un tableau commun. Ce n'est pas du formalisme, c'est la différence entre une base de décision et un mur de chiffres.

• OSWorld 2.0. Anthropic donne deux valeurs pour Fable 5.1, 77,9 % avec crédit partiel et 41,7 % en notation stricte. Côté OpenAI figure pour Astra une valeur unique de 72,6 %, sans mention du mode de notation. Opposer 72,6 à 77,9 est aussi infondé que l'opposer à 41,7. Tant que le mode de notation ne coïncide pas, il n'y a pas ici de comparaison, seulement une sélection.
• Fenêtre de contexte. Anthropic indique 1 000 000 de jetons, OpenAI 1 050 000 avec une entrée maximale de 922 000 jetons. Ces chiffres ne relèvent pas de la même échelle de capacité, car un jeton n'a pas le même sens selon le tokeniseur. Anthropic écrit lui-même que son tokeniseur actuel produit environ 30 % de jetons de plus pour un même texte que son propre précédent. Aucune donnée inter-fournisseurs sur les jetons par mot n'est publique, donc la question de savoir quel modèle contient le plus de texte reste sans réponse à partir de sources ouvertes.
• AutomationBench. Anthropic publie 31,4 % pour Fable 5.1. Dans son propre billet d'annonce, OpenAI revendique la première place sur le même benchmark mais n'y donne aucun chiffre. Il n'y a tout simplement rien à comparer.
• Les lignes où le chiffre Claude ne vient pas d'Anthropic. Pour ScreenSpot-Pro, FrontierMath Tier 4 v2, ExploitBench, ARC-AGI-3, GPQA Diamond et FrontierCode 1.1, seules des valeurs du côté d'OpenAI existent. Le chiffre Claude de ces lignes est la mesure de Claude par OpenAI, et dans plusieurs cas une mesure de Claude Fable 5 ou de Claude Opus 5, non de Fable 5.1. L'attribuer à Anthropic revient à citer la mauvaise source et, en partie, le mauvais modèle.
• Niveaux d'effort. Les deux fournisseurs autorisent une puissance de calcul variable par requête. Chez Anthropic, le réglage par défaut diffère même selon la surface : high dans Claude Code, medium dans claude.ai et Claude Cowork. Artificial Analysis mesure aux niveaux « max » et « xhigh ». Un chiffre de benchmark sans niveau d'effort déclaré n'est pas comparable à un chiffre obtenu à un autre niveau. Ce n'est pas un détail : c'est la raison la plus probable pour laquelle un même classement affiche trois résultats sur trois sites.

Un cas particulier mérite un avertissement : les 99,9 % qui circulent pour Astra sur ARC-AGI-3 portent dans la source la mention « harnais adaptateur » et voisinent avec 7,8 % pour le modèle précédent. Un écart d'environ 92 points au travers d'un changement de harnais décrit d'abord le harnais et ensuite seulement le modèle. Ce chiffre n'a sa place dans aucun titre.

Les classements tiers se contredisent ouvertement

Qui se méfie des chiffres des fournisseurs se tourne vers les classements indépendants. Ici, cela n'aide pas, car les classements se contredisent entre eux, sur un seul et même indice.

Artificial Analysis, dans son propre article du 3 septembre 2026, donne pour l'Intelligence Index : GPT-6 Astra 61, GPT-5.6 Sol 61, Claude Fable 5.1 66, ce dernier au niveau d'effort maximal avec une configuration de repli qui n'est pas le réglage par défaut de l'API. BenchLM rapporte le même indice différemment en septembre 2026 : GPT-5.6 Sol mène à 58,9 %, Fable 5.1 se situe à 53,7 %. llm-stats, consulté le 10 septembre 2026, indique Fable 5.1 à 56,8, Astra à 54,7 et Claude Opus 5 à 54,1.

Trois sources, un indice, trois classements. Ils ne peuvent pas tous être à jour. Les causes plausibles sont des dates de relevé différentes, des réglages d'effort différents et la confusion entre points et pourcentages. La conséquence pratique est simple : une valeur d'Intelligence Index sans le site, la date et le réglage d'effort n'est pas une information. Artificial Analysis signale d'ailleurs lui-même des résultats contrastés, dont un recul d'environ 80 points Elo sur GDPval-AA v2.

Reste l'arène. Là non plus il n'y a rien à en tirer : ni Claude Fable 5.1 ni GPT-6 Astra ne détient de position classée sur LMArena dans les instantanés de septembre 2026 accessibles ici, car l'Elo d'arène exige un volume de votes et accuse plusieurs semaines de retard sur les sorties de pointe. Même si ces valeurs existaient, elles seraient le mauvais instrument pour cette décision. La préférence humaine en comparaison aveugle mesure la qualité perçue des réponses sur des invites choisies par les votants, réagit fortement à la mise en forme et à la verbosité, et dit peu du travail agentique sur de longues durées. Pour un agent de code ou une plateforme de travail du savoir, ce n'est pas l'étalon sur lequel aligner un achat.

FrontierCode 1.1 : le chiffre qui dessert le fournisseur qui le publie

Une ligne de cette comparaison pèse plus que les autres, pour une raison méthodologique. Sur FrontierCode 1.1, GPT-6 Astra se situe selon les résultats rapportés par OpenAI à 53,3 %, donc derrière Claude Fable 5 à 53,5 %.

Deux précisions sont ici obligatoires. La valeur de comparaison concerne Claude Fable 5, non Fable 5.1, et Anthropic n'a publié aucun chiffre propre pour Fable 5.1 sur ce benchmark. L'écart est de 0,2 point de pourcentage, donc à l'intérieur de toute dispersion de mesure plausible.

C'est malgré tout le type de chiffre le plus digne de confiance que puisse contenir une annonce produit. Un fournisseur qui publie une ligne où son nouveau navire amiral se place derrière un modèle concurrent n'y a aucun intérêt commercial. Qui veut apprécier la solidité d'un tableau de benchmarks devrait d'abord chercher si de telles lignes y figurent. Un tableau où le fournisseur qui le publie gagne chaque ligne n'est pas une mesure, c'est une sélection.

Le sens s'inverse : résidence des données dans l'UE et zéro conservation

Jusqu'ici, Anthropic mène sur le prix et l'économie du cache et se situe à peu près à égalité sur les benchmarks. Sur la gouvernance des données, l'image s'inverse complètement, et pour une entreprise allemande c'est la colonne qui modifie une architecture.

Du côté d'Anthropic, cela figure dans sa propre documentation. Le paramètre inference_geo n'accepte que deux valeurs, global et us, et la seule région de stockage sélectionnable pour un espace de travail est us, figée à la création. Le volet conservation est plus explicite encore : Anthropic désigne Fable 5.1 et Mythos 5.1 (ainsi que Fable 5 et Mythos 5) comme des Covered Models qui exigent une conservation des données de 30 jours et ne sont pas disponibles sous zéro conservation sans autorisation expresse d'Anthropic. Une organisation soumise au ZDR doit activer la conservation de 30 jours pour un espace de travail précis, faute de quoi la requête est rejetée.

Du côté d'OpenAI, la documentation développeur sur le traitement des données indique que l'Europe (EEE et Suisse) prend en charge à la fois le stockage régional et le traitement régional via eu.api.openai.com, configuré par projet, les régions hors États-Unis exigeant une approbation pour les contrôles de surveillance des abus et un avenant de conservation modifiée. La même page liste les points de terminaison éligibles au ZDR, dont /v1/chat/completions et /v1/responses, et exclut explicitement Assistants, Threads, Vector Stores, l'affinage et Batches.

La précision importe ici plus qu'une formule lisse : aucune source trouvée n'affirme positivement que GPT-6 Astra est éligible au ZDR. Ce qui est documenté, c'est que ces points de terminaison prennent en charge le ZDR et qu'aucune exclusion spécifique au modèle n'est publiée pour gpt-6-astra. L'absence d'une restriction n'est cependant pas une autorisation. Qui fonde une architecture là-dessus devrait le faire confirmer contractuellement plutôt que de le déduire d'une lacune documentaire. Chez Anthropic, la situation est sans ambiguïté dans l'autre sens, car l'exclusion y est écrite noir sur blanc.

Une phrase souvent répétée doit également être corrigée : « Claude offre la résidence des données dans l'UE parce qu'il tourne sur AWS Francfort. » C'est exact précisément lorsque vous passez par un cloud partenaire tel qu'Amazon Bedrock ou Google Cloud, où le fournisseur de cloud fixe la région et agit comme sous-traitant. Cela ne vaut pas pour l'API propre d'Anthropic. Pour un routage régional garanti, Anthropic renvoie lui-même aux points de terminaison régionaux des clouds partenaires, moyennant un supplément de 10 % par rapport aux points de terminaison globaux. Pour un examen RGPD, cette distinction est le point central, car elle détermine avec qui le contrat de sous-traitance est conclu.

Article 50 : une différence que l'on ne peut prouver qu'à moitié

Depuis le 2 août 2026 s'appliquent les obligations de transparence de l'article 50 du règlement sur l'IA, qui exigent un marquage lisible par machine des contenus synthétiques. Anthropic indique que Fable 5.1 et Mythos 5.1 portent un filigrane textuel invisible dès le premier jour, et applique ce marquage dans le monde entier et pas seulement dans l'UE. Dans la limite des sources disponibles, c'est une différence réelle.

Cette phrase exige toutefois ses deux moitiés. Aucune source n'a été trouvée indiquant si la sortie textuelle de GPT-6 Astra est marquée. L'approche de provenance documentée d'OpenAI, les Content Credentials C2PA et SynthID, concerne l'image et l'audio ; les pages accessibles ne disent rien du texte. De cette lacune il ne découle pas qu'OpenAI ne marque pas le texte. Nous ne l'affirmons donc pas. OpenAI publie séparément des indications clients sur le règlement sur l'IA.

Et le filigrane d'Anthropic porte moins loin que le terme ne le suggère. Anthropic écrit dans sa propre aide qu'un marquage détecté signale qu'un contenu a peut-être été traité par Claude, qu'il n'est pas pleinement concluant et qu'il n'établit pas à lui seul la provenance du contenu. L'API de détection correspondante est de surcroît en aperçu privé pour des organisations sélectionnées. Comme brique d'une argumentation de conformité, le filigrane est utilisable ; comme moyen de preuve, non.

Ce que cela signifie pour une décision en Allemagne

Si vous ne retenez qu'une règle de cette comparaison, retenez celle-ci : avec deux modèles de pointe proches sur les chiffres défendables et affichés au même prix, une ligne de benchmark tranche rarement. L'écart sur Terminal-Bench 4.0 est de 1,9 point de pourcentage, sans harnais déclaré. Sur FrontierCode 1.1, il est de 0,2 point en sens inverse, face à un modèle Claude plus ancien. De tels écarts se déplacent à la sortie suivante, et ils ne changent aucune architecture.

Ce qui change une architecture se trouve dans la colonne gouvernance. Une organisation tenue au zéro conservation des données ne peut pas employer Claude Fable 5.1 via l'API propre d'Anthropic sans autorisation expresse, aussi bon que soit le modèle. Une organisation exigeant une inférence dans l'UE ne trouve cette voie chez Anthropic qu'au travers d'un cloud partenaire, avec le supplément correspondant et un autre sous-traitant au contrat. À l'inverse, l'avantage d'Anthropic sur la lecture de cache est réel et croît avec la part de travail agentique où le même contexte est lu des centaines de fois.

En pratique : clarifiez d'abord les obligations, ensuite les coûts, et les benchmarks en dernier. Dans l'ordre inverse, vous construisez un système qui mesure bien et échoue devant la protection des données. Et pour chaque chiffre qu'on vous présente, vérifiez trois choses : qui l'a rapporté, quand, et à quel niveau d'effort.

Ce que la publication elle-même a changé pour une entreprise allemande est traité dans notre article sur Claude Fable 5.1. Le comportement du modèle dans le travail de projet en cours est traité dans capacités en pratique. Et si la réponse à la question de gouvernance est que les données ne doivent pas quitter la maison, le chemin passe par l'arbitrage entre l'hébergement sur site et le cloud, non par un classement.

CE QUE LA RECHERCHE VISUELLE NE FOURNIT VOLONTAIREMENT PAS

Les modèles de retrieval visuel trouvent la bonne page, même dans un scan difficile. Mais ils vous renvoient une image, pas du texte. Vous ne pouvez pas en copier une ligne sans effort, ni poser une recherche en texte intégral sur l'archive, ni construire une piste de vérification lisible par machine. Pour tout cela, il vous faut du texte reconnu. Ce n'est pas une faiblesse de la nouvelle approche, mais une répartition assumée des tâches : la recherche sur l'image, l'extraction de texte par OCR, chaque étape pour ce qu'elle sait faire de mieux.

CE QUE SAIT FAIRE PADDLEOCR-VL

Avec PaddleOCR-VL, Baidu a présenté un modèle OCR ouvert qui atteint des performances de pointe avec seulement 0,9 milliard de paramètres (projet). Il reconnaît texte, tableaux, formules et diagrammes dans 109 langues et reconstruit la structure sémantique d'un document. Sur le benchmark OmniDocBench v1.5, il se place en tête avec environ 94,5 % de précision. Il est sous licence Apache-2.0, donc librement utilisable en usage commercial et exploitable localement. Pour une PME, cela signifie : une reconnaissance de texte puissante, sans frais récurrents et sans fuite de données.

L'ARCHITECTURE HYBRIDE

En pratique, les deux voies fonctionnent côte à côte. La recherche visuelle trouve rapidement les pages pertinentes en respectant la mise en page. Là où il faut en tirer du texte solide, par exemple pour une ligne de facture, une clause de contrat à citer ou une entrée dans l'ERP, l'OCR prend le relais sur ces quelques pages précises. Il n'est pas nécessaire de passer toute l'archive à l'OCR, mais seulement ce que la recherche a déjà marqué comme important. Cela garde la pipeline légère et évite que les erreurs d'OCR ne s'infiltrent dès le départ dans la recherche.

LA LIGNE PRAGMATIQUE

L'opposition binaire est ici la mauvaise posture. La recherche visuelle améliore la découverte, l'OCR améliore le traitement ultérieur. Qui comprend les deux comme des outils aux tâches claires construit une base de connaissances plus robuste que celui qui mise dogmatiquement sur un seul camp. La façon dont les briques s'assemblent, de l'encodeur à la base vectorielle, figure dans l'aperçu du stack.

Pour une PME qui traite chaque jour des contrats, des manuels techniques et des factures de plusieurs pages, c'est là la nouvelle la plus intéressante. Ce n'est pas la reconnaissance de texte qui gagne quelques points, mais : un document de 80 pages n'a plus besoin d'être découpé puis réassemblé, et aucun document n'a besoin de quitter la maison pour cela.

CE QU'UNLIMITED-OCR FAIT DIFFÉREMMENT

Le cœur est une attention modifiée dans le décodeur qui maintient la mémoire constante. Les modèles OCR classiques fondés sur les transformeurs laissent croître le cache KV avec la longueur du document. Plus le PDF est long, plus il faut de mémoire, jusqu'à ne plus tenir dans un seul traitement.

Unlimited-OCR remplace cette partie par la Reference Sliding Window Attention (R-SWA). Le cache KV reste ainsi constant, quelle que soit la longueur du document. C'est exactement ce que désigne le terme one-shot long-horizon parsing : un long document est lu en une passe, au lieu d'être découpé en sections puis réassemblé après coup.

La démarche d'entraînement est remarquable. L'équipe n'est pas partie de zéro, mais a poursuivi l'entraînement du checkpoint DeepSeek-OCR : encodeur gelé et seul le décodeur ajusté sur environ 4 000 étapes. Le modèle s'inscrit ainsi dans la lignée directe de DeepSeek-OCR, que nous avons déjà situé dans le contexte du stack. Code et poids sont ouverts sur GitHub.

POURQUOI LE CACHE KV CONSTANT COMPTE

Le vrai problème des longs documents n'est pas la page isolée, mais la continuité d'une page à l'autre. Quand un modèle découpe un document de 60 pages en blocs de dix pages, c'est précisément ce qui compte dans le quotidien B2B qui se perd : un tableau qui court sur un saut de page, une clause qui renvoie à une section précédente, une ligne dont la grandeur de référence figure vingt pages plus haut.

Un cache KV constant permet de garder tout le document dans un seul contexte. La mémoire ne croît pas avec la longueur, donc la structure reste préservée sur toutes les pages. Au passage, cela accélère : Baidu annonce en mode Base 5 580 tokens par seconde contre 4 951 pour DeepSeek-OCR ; avec une limite de sortie de 6 000 tokens, l'écart est d'environ 35 pour cent.

Côté précision, Unlimited-OCR se situe sur OmniDocBench v1.5 à 93,23 points, 6,22 au-dessus de la base DeepSeek-OCR, et à 93,92 sur v1.6. Ce sont les chiffres du papier. Sur vos propres documents, ce qui compte au bout du compte, c'est la manière dont le modèle traite vos tableaux, vos tampons et vos formulaires, pas la moyenne d'un jeu de test public. La démarche est apparentée à celle des LLM subquadratiques, qui rendent le contexte long on-prem plus abordable.

OÙ CELA CHANGE QUELQUE CHOSE POUR LES PME

L'utilité naît là où de longs documents structurés doivent devenir des données propres et interrogeables. Quelques points concrets :

• Contrats et accords-cadres. Renvois croisés et annexes restent lisibles dans leur continuité, au lieu de se disloquer aux limites des blocs.
• Manuels techniques et normes. De longs documents avec figures, tableaux et sections numérotées en une seule passe.
• Factures et justificatifs de plusieurs pages. Un texte proprement extrait est le préalable à un traitement structuré, par exemple vers la facturation électronique.
• Archives et dossiers. Des fonds qui n'existaient jusqu'ici que sous forme de scans deviennent lisibles par machine, sans les confier à un service cloud.

Dans presque tous les cas, l'OCR n'est pas l'objectif, mais la première étape. Un texte proprement analysé est le fondement d'une base de connaissances avec RAG : meilleure est l'analyse, mieux la recherche retrouvera ensuite le bon passage.

OCR OU RECHERCHE DOCUMENTAIRE VISUELLE ?

Toutes les tâches documentaires n'ont pas besoin de reconnaissance de texte classique, et c'est un arbitrage honnête. Il existe désormais toute une branche qui ne convertit pas d'abord les documents en texte, mais les interroge sous forme d'image, avec des modèles comme ColPali ou ColQwen. Nous avons décrit à part cette approche sans OCR.

La règle empirique qui a fait ses preuves chez nous :

• Vous avez besoin des caractères réels (montants de factures, clauses de contrat, extraction structurée, transmission à un autre système) : alors l'OCR reste difficilement contournable, et un modèle comme Unlimited-OCR y est très solide.
• Vous avez besoin du bon passage, pas du texte intégral (répondre à une question sur un vaste fonds, retrouver une figure) : alors la recherche documentaire visuelle peut être la voie la plus directe.

Souvent, c'est les deux côte à côte. Unlimited-OCR rend la partie OCR de ce stack moins coûteuse et plus fiable sur les longs documents.

CE QUE JE VÉRIFIERAIS AVANT LA MISE EN PRODUCTION

Un bon score de benchmark est une raison de tester le modèle, pas une raison de le mettre en production. Avant de placer Unlimited-OCR dans un processus client, je vérifierais quatre choses :

🔸 Documents allemands et écriture manuscrite. Les chiffres de benchmark disent peu de chose sur les formulaires allemands, les vieux dossiers ou les annotations manuscrites. Cela mérite un jeu de test propre issu de documents réels.

🔸 Tableaux et mise en page. Sur les documents B2B, la fidélité des tableaux et des colonnes décide de l'utilité. Ici, la comparaison directe avec le stack existant en vaut la peine.

🔸 Matériel et exploitation. Un MoE de 3 Md avec environ 500 M de paramètres actifs est réaliste on-prem. Ce que cela signifie concrètement en mémoire GPU et en débit doit être mesuré avant le déploiement, pas estimé.

🔸 Licence et provenance. La licence MIT autorise l'usage commercial on-prem sans note de bas de page. Que la trace du modèle mène à l'un des auteurs de DeepSeek-OCR est un signal de qualité, mais ne remplace pas votre propre examen.

Ce qui m'intéresse vraiment dans cette publication, c'est moins le modèle lui-même que la direction : de longs documents en une passe, assez petits pour votre propre centre de données, sous une licence qui ne restreint personne. C'est précisément là que le traitement documentaire devient concret dans les PME. Lesquels de vos documents feriez-vous passer en premier ?

AU-DELÀ DU PROMPT

L'ingénierie des prompts règle la question. L'ingénierie du contexte conçoit l'environnement dans lequel le modèle décide. Pour une tâche ponctuelle, un bon prompt suffit. Pour un agent qui s'exécute sur de nombreuses étapes, lit des outils et porte une mémoire, le prompt n'est qu'une petite part de ce que le modèle voit. Le reste, ce que vous récupérez, ce que vous retenez, quels outils vous exposez et comment, c'est le contexte, et il décide bien davantage du résultat. C'est pourquoi étendre un harnais d'agent est surtout un travail de contexte.

LES QUATRE ÉCHECS À DÉJOUER PAR LA CONCEPTION

La plupart des échecs d'agents remontent à l'un de quatre problèmes de contexte :

• Surcharge du contexte. Trop dans la fenêtre. Le modèle perd le fil, et le coût comme la latence grimpent. Plus de contexte n'est pas un meilleur contexte.
• Empoisonnement du contexte. Un fait faux ou périmé entre dans la fenêtre et le modèle le traite comme vérité. Un seul mauvais extrait récupéré peut faire dérailler une réponse.
• Gestion des tokens. La fenêtre est finie. Sans plan pour ce qu'on garde et ce qu'on écarte, le détail important est chassé par le bruit.
• Mémoire périmée. Les agents à longue durée accumulent un contexte qui ne s'applique plus, et agissent dessus.

Nommer l'échec, c'est la moitié du remède. Chacun a une contre-mesure concrète.

DES PRATIQUES QUI TIENNENT

Quelques schémas reviennent dans les configurations qui restent fiables :

1. Récupérer, ne pas déverser. Tirez les quelques passages pertinents avec un bon retrieval plutôt que de tout coller. C'est tout l'intérêt du RAG, et c'est l'ingénierie du contexte appliquée aux données.
2. Élaguer au fil de l'eau. Appliquez une édition à base de règles au sein du harnais pour garder la fenêtre légère : écartez ce dont une étape n'a plus besoin.
3. Résumer les longs historiques. Remplacez une longue transcription par un résumé fidèle avant qu'elle n'évince la tâche.
4. Commencer simple, monter en charge au besoin. N'ajoutez mémoire et outils que quand un échec réel l'exige, pas par défaut.

L'instinct d'en ajouter davantage est le piège. La discipline, c'est la soustraction.

POURQUOI C'EST LA VRAIE INGÉNIERIE

Un modèle plus grand corrige rarement un problème de contexte ; il échoue juste plus cher. Le travail qui fait passer un agent de la démo au fiable est presque entièrement un travail de contexte : ce qu'il voit, quand, et ce qu'on lui fait oublier. Pour des entrées très longues, l'architecture du modèle compte aussi, et c'est là qu'interviennent les approches subquadratiques, mais pour la plupart des équipes le gain est dans le contexte, pas dans les paramètres.

LE PROBLÈME N'A JAMAIS ÉTÉ L'ANIMATION, MAIS LA PASSATION

Jusqu'ici, le mouvement d'interface naissait hors de Figma. La designeuse le construisait dans un second outil, exportait une vidéo ou une description, et le développement devait reconstruire les courbes et les durées, souvent à l'œil. De la précision se perd au passage : une courbe d'accélération devient une idée approximative, un timing une estimation. C'est précisément cette rupture, et non le manque d'outils d'animation, qui a rendu le mouvement incohérent dans beaucoup de produits.

CE QU'APPORTE CONCRÈTEMENT FIGMA MOTION

Trois choses changent nettement le flux de travail :

• Timeline dans le canvas. Keyframes, presets et contrôle du mouvement se trouvent là où le design vit déjà. Aucun passage vers un second outil.
• Le mouvement comme partie du design system. Un composant est animé une fois, et le mouvement voyage comme la couleur ou la typographie à travers chaque écran et chaque fichier. C'est le point qui impose la cohérence au lieu de l'espérer.
• Passation lisible. En Dev Mode, toute la timeline est visible : chaque valeur de timing, chaque courbe d'accélération, chaque keyframe. L'export se fait en CSS, JSON ou React prêt pour un framework, avec en plus MP4, WebM, SVG animé et GIF.

Le développement lit ainsi le mouvement au lieu de l'interpréter. C'est là le véritable déplacement.

OÙ SE TROUVE LE HIC

Un outil intégré n'est pas automatiquement le bon pour chaque cas. Le travail de motion complexe et narratif, par exemple un film de marque élaboré, reste l'affaire d'outils spécialisés. Figma Motion vise l'animation d'interface : états, transitions, micro-interactions, c'est-à-dire précisément ce dont le produit a besoin au quotidien et qui souffrait jusqu'ici de la rupture de passation. Pour cette classe de mouvement, l'intégration est le gain. Pour tout ce qui va au-delà, la boîte à outils reste mixte.

POUR QUI LE COUP D'ŒIL EN VAUT LA PEINE

Qui entretient un produit à motifs d'interface récurrents en profite le plus : le mouvement défini une fois reste cohérent, et la mise en œuvre reçoit des valeurs exactes plutôt que des approximations. Le mouvement n'est pas ici un décor, mais une part de la compréhensibilité d'une interface, un point que nous détaillons dans le rôle de l'UX dans la construction logicielle. Figma Motion rend enfin cette part modifiable en un seul endroit.

LE MÉCANISME, SIMPLEMENT

Le RAG simple encode votre requête, trouve les passages les plus proches, et répond à partir d'eux. RAG-Fusion ajoute deux étapes en amont. D'abord, un modèle écrit une poignée de requêtes alternatives qui signifient la même chose sous différents angles. Ensuite, il récupère pour chacune et fusionne les listes classées par fusion de rangs réciproques, qui récompense les passages bien classés sur plusieurs requêtes plutôt qu'une seule. La réponse est ensuite rédigée à partir de cet ensemble fusionné et reclassé.

POURQUOI L'ÉTAPE DE FUSION COMPTE

Une requête unique est une supposition unique sur la façon dont la réponse est formulée dans vos documents. Les archives réelles emploient synonymes, abréviations et formulations différentes pour la même chose. En posant la question de plusieurs façons et en récompensant ce qui se classe régulièrement haut, RAG-Fusion fait remonter le passage qu'une seule formulation aurait manqué. La fusion de rangs réciproques est ici l'ouvrière discrète : elle combine des listes sans besoin de scores comparables, ce qui explique aussi pourquoi elle apparaît dans les configurations hybrides et à interaction tardive comme celles derrière Qdrant et ColQwen.

QUAND ÇA AIDE ET QUAND ÇA NUIT

RAG-Fusion justifie son coût sur les questions ambiguës ou lourdes en terminologie, où une seule formulation est un pari faible. Il coûte plus : plusieurs récupérations et une étape de génération par question, donc ce n'est pas une latence gratuite. Et il a un vrai mode d'échec. Si les variantes de requête générées s'écartent de ce que vous vouliez vraiment dire, elles tirent des passages hors sujet et la réponse s'égare. Le remède est de garder les requêtes générées étroitement liées à l'intention d'origine, et de mesurer, non de supposer, que le rappel s'est amélioré.

OÙ IL SE SITUE PARMI LES OPTIONS

RAG-Fusion est l'une des façons d'améliorer le retrieval, pas un remplacement d'un bon retrieval. Avant d'y recourir, assurez-vous que les bases tiennent : des chunks propres, un modèle d'embedding solide, et un magasin vectoriel adapté à la tâche. Pour les documents visuellement denses, le plus grand levier est souvent le retrieval visuel plutôt que davantage de variantes de requête. Utilisez F-RAG là où la question est réellement ambiguë et où le gain de rappel vaut les appels supplémentaires.

TROIS SORTIES, EN TERMES SIMPLES

Chacune de ces sorties est intervenue à une quinzaine de jours des autres en juin 2026, et chacune est une chose d'une nature différente. Il vaut la peine d'être précis, car deux d'entre elles sont largement mal décrites.

GLM-5.2, de Z.ai à Pékin, est sorti le 17 juin. C'est un modèle open-weight de type Mixture-of-Experts, environ 750 milliards de paramètres dont quelque 40 milliards actifs, un contexte d'un million de tokens, et surtout une licence MIT avec les poids publiés sur HuggingFace.

Sakana Fugu, de Sakana AI à Tokyo, est sorti le 22 juin. Ce n'est pas un modèle conventionnel, et le cadrage courant se trompe : Fugu est un orchestrateur entraîné qui appelle un pool d'autres modèles et synthétise leur travail. Il est uniquement en API, offert comme un point de terminaison compatible OpenAI.

Claude Fable 5, d'Anthropic aux États-Unis, est sorti le 9 juin. La seconde erreur courante est de classer Fable comme un palier rapide ou créatif. C'est le fleuron, le modèle le plus capable largement diffusé par Anthropic, encadré par la sécurité, cloud uniquement, à 10 et 50 dollars par million de tokens. Ses chiffres de benchmark sont solides ; pour cet article, ils sont aussi hors sujet.

LA SEULE COMPARAISON QUI SURVIT À L'ACHAT

Retirez le classement et alignez-les sur les dimensions dont un acheteur B2B allemand est réellement responsable. Le tableau est clair, et il ne porte pas sur lequel est le plus intelligent.

Deux réserves honnêtes appartiennent à ce tableau. La voie par défaut de GLM-5.2, l'API Z.ai, relève des lois chinoises sur les données, avec leurs dispositions d'accès obligatoire, ce qui est précisément pourquoi les poids ouverts comptent : l'auto-hébergement en UE neutralise ce risque. Et la revendication de parité frontière de Fugu est entièrement auto-déclarée, affaiblie par le fait que Fable et le modèle Mythos restreint ne sont même pas dans son pool. Je ne miserais pas une décision sur le benchmark de l'un ou l'autre fournisseur.

CE QUE JE DIS RÉELLEMENT À UN CLIENT

Je ne recommande pas l'un de ceux-ci dans l'abstrait. J'ajuste la posture à ce que le client peut financer et à ce dont il est responsable.

🔸 GLM-5.2 est le pari on-prem. Les poids ouverts MIT sont tout l'enjeu : vous pouvez le faire tourner dans votre propre centre de données, et les prompts ne quittent jamais votre réseau. Le hic est l'empreinte GPU, environ 744 gigaoctets en FP8, il convient donc au client qui peut financer le matériel et a besoin que les données restent dans le bâtiment. C'est l'histoire de souveraineté la plus nette des trois.

🔸 Claude Fable 5 est le pari de l'assurance gérée. Vous louez une capacité à un fournisseur américain, au prix le plus élevé ici, avec un vrai encadrement de sécurité et un routage régional des données sur les grands clouds. Pour une équipe qui veut un modèle de premier plan sans posséder le stack, et qui peut vivre avec une dépendance au cloud, c'est la meilleure option gérée.

🔸 Sakana Fugu est le pari de la commodité, avec l'histoire de contrôle la plus faible. Une API qui route à travers un pool de modèles est astucieuse, et le Japon est une géopolitique plus douce que la Chine. Mais vous ne pouvez pas le faire tourner on-prem, vous ne choisissez pas quel modèle voit les données, et les preuves sont minces. Je le traiterais comme intéressant, pas comme un choix par défaut pour un travail réglementé.

C'est la même leçon que Claude Fable 5 a enseignée à la dure quand un modèle antérieur a été coupé en 72 heures : une capacité louée est révocable, et le contrôle est une propriété du stack, pas du score. C'est pourquoi je continue d'orienter les clients vers des modèles open-weight qu'ils peuvent réellement posséder.

LA QUESTION QUI MÉRITE D'ÊTRE CONÇUE

Si vous ne retenez qu'une chose de tout ceci, que ce soit la question, pas le classement. Les modèles échangeront de nouveau leurs places au classement dans le trimestre ; cette partie est du bruit. La question durable est celle qu'un responsable des achats devrait poser dès le premier jour : lequel de ceux-ci pourrez-vous encore faire tourner, auditer et vous offrir quand le fournisseur changera les conditions ? Pour la plupart des clients réglementés avec qui je travaille, cette question se répond d'elle-même, et elle ne pointe pas vers le benchmark le plus élevé. Alors avant de choisir le modèle le plus intelligent, que vous coûterait-il de le perdre ?

CE QU'EST RÉELLEMENT GEMINI OMNI

Précisons d'abord le nom, car le marketing le brouille. La famille est Gemini Omni et le premier modèle est Gemini Omni Flash. Il accepte texte, image, audio et vidéo en entrée, et au lancement il produit une seule sortie : de la vidéo, en clips d'environ 10 secondes avec audio nativement synchronisé. Google le décrit comme un pas vers un modèle du monde, c'est-à-dire qu'il tente de maintenir physique, gravité et cohérence spatiale constantes à travers une scène générée, et il tourne sur les TPU de 8e génération de Google, déclinées en variantes d'entraînement et d'inférence.

Une correction honnête compte pour un lecteur technique : Omni est présenté comme any-to-any, mais tel qu'il a été livré c'est du toute-entrée-vers-vidéo. Les sorties image et audio sont sur la feuille de route, pas dans le produit. Ce n'est donc pas un assistant omni conversationnel en temps réel, et ce n'est pas encore le système universel any-to-any que le nom suggère. C'est un générateur de vidéo très capable et souple sur les entrées, ce qui est une chose plus étroite et plus utile autour de laquelle planifier.

ANNONCÉ, LIVRÉ ET DISPONIBLE SONT TROIS CHOSES DIFFÉRENTES

La distinction la plus utile pour un acheteur est que ces trois états ne sont pas identiques, et Omni se trouve dans des états différents selon qui vous êtes. Il est livré aux consommateurs et aux créateurs, et seulement annoncé pour tous ceux qui construisent sur une API.

La lecture pratique pour une entreprise UE est directe. Si vous avez besoin aujourd'hui d'une résidence UE de niveau RGPD pour la génération vidéo, Omni ne peut pas vous la donner, car sa voie entreprise n'existe pas encore. L'option prise en charge sur le propre stack de Google reste Veo 3.1 sur Vertex AI, que vous pouvez épingler à une région UE. C'est le même schéma que nous voyons sans cesse avec les nouveaux lancements de modèles, où la démo et le produit déployable sont séparés de plusieurs mois.

CE QU'UNE ENTREPRISE ALLEMANDE DEVRAIT FAIRE MAINTENANT

Traitez Omni comme un signal à suivre, pas comme un outil à adopter ce trimestre. Trois gestes concrets.

• Utilisez Veo 3.1 épinglé à une région pour la vidéo de production aujourd'hui. Il a une vraie API Vertex, des régions UE et un SLA. Omni n'a rien de tout cela pour l'instant, il n'a donc pas sa place dans une pipeline de production maintenant.
• Planifiez tôt l'histoire de provenance. Omni intègre un filigrane SynthID sur chaque clip. Pour du contenu réglementé ou public, intégrez à votre processus l'attente que la vidéo générée par IA soit étiquetée et traçable, quel que soit le modèle qui l'emporte.
• Surveillez deux risques, pas seulement la capacité. Des testeurs ont reproduit des personnages de marque reconnaissables dans les sorties d'Omni, ce qui est une réelle exposition en propriété intellectuelle pour un usage commercial, et la cohérence visuelle dérive encore sur les mouvements rapides. Le plafond de 10 secondes est une limite d'UX, pas un plafond du modèle, attendez-vous donc à ce qu'il bouge.

Le point durable est celui que le lancement fait par accident : un modèle que vous pouvez voir dans une keynote n'est pas un modèle que vous pouvez déployer sous contrat. Séparez les deux, et le battage devient un point de feuille de route plutôt qu'une erreur d'achat.

CE QUI A RÉELLEMENT ÉTÉ LIVRÉ EN 2025 ET 2026

Le titre est la stabilité après des années de remous. LangChain 1.0 et LangGraph 1.0 ont tous deux atteint une version stable le 22 octobre 2025, avec un engagement de ne pas introduire de changements cassants jusqu'à la 2.0. La nouvelle abstraction phare du framework, create_agent, tourne désormais sur le runtime LangGraph en dessous, si bien que la boucle d'agent est un graphe LangGraph. C'est le signal le plus clair de la fusion : le framework et le runtime d'orchestration ne sont plus des choix séparés.

LangGraph 1.0 a apporté l'exécution durable en natif : l'état est enregistré automatiquement, si bien qu'un flux à longue durée ou avec humain dans la boucle reprend après une interruption ou un redémarrage de serveur. LangSmith, la couche d'observabilité et d'évaluation, a ajouté un support complet d'OpenTelemetry en mars 2026, ce qui signifie que vous pouvez lui envoyer des traces depuis du code qui n'utilise pas du tout LangChain. Le tableau commercial a suivi le tableau technique : LangChain Inc a levé une série B de 125 millions de dollars à une valorisation de 1,25 milliard en octobre 2025, et a renommé LangGraph Platform en LangSmith Deployment, regroupant déploiement, observabilité et évaluation en un seul produit.

QUATRE NOMS, DEUX ENTREPRISES

Démêler qui fait quoi est la chose la plus utile avant de choisir. La plupart des articles le brouillent ; le clarifier change la décision.

LangFlow est celui qui trompe les gens. Ce n'est pas un produit de LangChain Inc. C'est un constructeur visuel open source créé par DataStax, dont la maison mère a été rachetée par IBM en février 2025, et il pointe désormais vers watsonx d'IBM. La rime des noms est une coïncidence. Si votre besoin est un canvas glisser-déposer pour des gens qui n'écrivent pas de Python, LangFlow est le candidat ; ce n'est pas une couche du stack LangChain.

LA DÉCISION QUE LA PLUPART DES ÉQUIPES AFFRONTENT VRAIMENT

Une fois les noms clairs, le choix est généralement un court arbre de décision, et vous avez rarement besoin des quatre.

• Besoin d'orchestration durable ? LangGraph est la pièce la plus solide, et celle que même les critiques tendent à respecter. État reprenable, checkpointing et humain dans la boucle sont de la vraie ingénierie, pas des enrobages.
• Besoin d'observabilité et d'évaluation ? LangSmith est capable, mais il vous couple à l'écosystème. Langfuse est le contrepoids open source et auto-hébergeable, et l'échappatoire la plus citée. Maintenant que LangSmith parle OpenTelemetry, vous pouvez tracer depuis du code non-LangChain, ce qui adoucit la dépendance.
• Vous construisez un agent simple ? Les SDK des fournisseurs (l'OpenAI Agents SDK, le Claude Agent SDK) et Pydantic AI sont des alternatives crédibles et plus légères. La plainte dominante des praticiens est l'empilement d'abstractions du framework, et plusieurs équipes rapportent avoir réduit code et maintenance en passant à un stack plus mince.
• Des non-développeurs qui prototypent ? LangFlow, avec la réserve qu'un prototype sur canvas a toujours besoin de la même gouvernance et évaluation avant d'être livré.

C'est la même leçon que nous avons tirée en comparant comment câbler l'IA dans un stack via une API, un serveur MCP ou une CLI : les outils sont des couches, et vous choisissez par la tâche, pas par la nouveauté. Cela fait aussi écho à ce que nous avons trouvé en examinant les constructeurs d'agents no-code pour les PME, où le canvas vous donne une démo rapidement et s'arrête exactement à la gouvernance, la fiabilité et le coût.

STABLE NE VOULAIT PAS DIRE DURCI

Une réserve compte pour un public d'affaires : la 1.0 a acheté la stabilité de l'API, pas une posture de sécurité durcie. Un ensemble de CVE a touché LangChain et LangGraph fin 2025 et début 2026, mené par une faille de désérialisation qui pouvait fuir des clés API et des secrets d'environnement, notée CVSS 9.3 et surnommée LangGrinch. Deux autres ont suivi : une traversée de chemin dans l'API de chargement de prompts, et une injection SQL dans le checkpointer SQLite de LangGraph.

La lecture pratique n'est pas d'éviter le framework. C'est de le traiter comme toute autre dépendance qui touche à vos secrets et à vos données : figez les versions, appliquez les correctifs, et incluez-le dans votre modèle de menace. Un framework qui orchestre des appels d'outils et détient des identifiants fait partie de votre surface d'attaque, et « stable » sur le numéro de version dit peu de chose à ce sujet. Pour un déploiement réglementé ou on-prem, cette revue appartient à la même conversation que la résidence des données, pas après la mise en service.

LE PROBLÈME DU VECTEUR UNIQUE

La recherche vectorielle classique comprime tout un paragraphe ou toute une page en un seul vecteur. C'est économe, mais cela moyenne ce qui compte localement. Si le montant recherché figure dans une cellule de tableau précise, ce lien disparaît dans la moyenne de toute la page. Pour du texte courant propre, cela suffit souvent. Pour les documents contre lesquels la recherche visuelle se mesure vraiment, cela ne suffit pas.

LATE INTERACTION, EN UNE PHRASE

Late Interaction conserve de nombreux vecteurs par page et les compare tard, seulement au moment de la recherche. Le modèle produit un vecteur par token pour la requête et un vecteur par extrait pour la page. L'évaluation s'appelle MaxSim : pour chaque token de requête, on cherche l'extrait de page qui correspond le mieux, et ces meilleures correspondances sont sommées. Ainsi, le mot « solde » peut s'accrocher précisément à la cellule de tableau où il figure. La technique vient de ColBERT et a été transposée aux images avec ColPali. Pour voir toute la boîte à outils : le stack sans OCR situe les modèles.

OÙ QDRANT ENTRE EN JEU

Late Interaction a besoin d'une base de données qui comprend plusieurs vecteurs par objet. Qdrant prend en charge de tels multi-vecteurs directement, sans pré- ni post-traitement, et peut porter tout modèle Late Interaction comme ColBERT ou ColPali (doc). L'architecture habituelle est à deux étages : une première recherche rapide avec des vecteurs denses ordinaires réduit les candidats, puis MaxSim n'évalue précisément que ces quelques pages. L'index reste ainsi abordable, car les coûteux vecteurs de tokens n'ont pas à être pleinement indexés, mais servent au re-ranking.

CE QUE CELA SIGNIFIE EN PRATIQUE

Vous obtenez des résultats qui respectent la mise en page, sans rendre la recherche hors de prix. Le prix est davantage de mémoire par page et un peu plus de complexité à la construction. Les deux sont maîtrisables si l'on planifie l'étage de re-ranking dès le départ plutôt que d'indexer pleinement chaque vecteur de token. Pour les contextes très longs, il vaut la peine de regarder les modèles subquadratiques ; pour l'idée de base du retrieval, Qu'est-ce que le RAG reste l'entrée en matière.

Ce qui rend n8n solide

n8n est une automatisation de flux à base de nœuds, auto-hébergée ou en cloud, avec plus de 400 intégrations plus un nœud HTTP et des nœuds code pour tout le reste (n8n). Le point décisif pour les secteurs réglementés : il tourne dans la maison, les données ne quittent pas l'infrastructure. La licence fair-code autorise un usage interne sans frais. Qui a besoin de sa propre logique, de ses propres points de terminaison et d'un contrôle total des données est ici à sa place. Le prix en est l'exploitation : vous hébergez, mettez à jour et sécurisez vous-même.

Ce qui rend Make.com solide

Make.com est un service cloud à scénarios visuels qui se passe d'exploitation propre. On assemble un flux en cliquant et il tourne, sans serveur, sans maintenance. Pour des équipes sans profondeur technique ou pour une idée rapide, c'est le chemin le plus court. La facturation se fait à l'opération, donc par étape exécutée. C'est bon marché pour de petits volumes et peut croître de façon désagréable pour de gros flux fréquents. Le revers de la commodité : les données passent par un service tiers, et la logique reste dans ses limites.

La décision en un tableau

La ligne de partage est claire : contrôle des données et profondeur contre rapidité sans exploitation propre.

Notre conseil pragmatique

Prototypez vite, hébergez à dessein. Pour un premier test qui ne doit que montrer si un flux tient, Make.com est souvent plus rapide. Dès que des données sensibles, de gros volumes ou une logique propre entrent en jeu, n8n l'emporte, car il tourne dans la maison. Et là où l'automatisation touche à de vraies tâches d'IA, il vaut la peine de regarder les agents no-code et leurs limites : automatisation et agent ne sont pas le même outil.

POURQUOI LA TAILLE DEVIENT ICI UN OBSTACLE

Les modèles de retrieval visuel comme ColPali ou ColQwen sont précis, mais aussi volumineux. En on-prem, donc sur son propre matériel dans la maison, cela devient vite une question de coût : les grands modèles exigent des GPU puissants, plus de mémoire, plus d'électricité. Pour beaucoup d'architectures de PME, ce n'est pas la qualité l'obstacle, mais la facture matérielle. C'est précisément là qu'un modèle plus petit fait levier.

CE QUE MODERNVBERT FAIT DIFFÉREMMENT

ModernVBERT est un encodeur vision-langage compact de 250 M de paramètres (papier). Il relie un encodeur de texte moderne de 150 M fondé sur ModernBERT à un petit encodeur d'image et les aligne l'un sur l'autre via un objectif de Masked Language Modeling. ColModernVBERT est la variante affinée pour le retrieval. Le résultat selon le papier : malgré environ dix fois moins de paramètres, il se situe seulement 0,6 nDCG@5 sous ColPali sur le benchmark agrégé ViDoRe et atteint ainsi des valeurs pour lesquelles il fallait sinon des modèles presque dix fois plus gros. Modèle et code sont disponibles en accès libre.

POURQUOI CELA COMPTE POUR LA SOUVERAINETÉ

Un modèle petit, ouvert et puissant est précisément la combinaison qui rend possible l'exploitation locale. Il tient sur un GPU modeste, les poids sont ouverts, et les documents restent dans la maison, car la recherche ne va pas vers un point de terminaison tiers. Ce n'est pas une fonctionnalité de sécurité ajoutée après coup, mais une propriété de l'architecture. Le contexte plus large, pourquoi local et ouvert vont de pair, nous le traitons dans On-Premise contre cloud.

QUAND LE PETIT MODÈLE EST LE BON CHOIX

On n'a pas toujours besoin du plus grand modèle. Si votre matériel est limité et vos documents des pièces d'affaires typiques, ColModernVBERT est souvent le choix plus honnête que ColQwen : presque la même qualité, une fraction du coût. Si vous avez besoin du dernier soupçon de précision sur des pages particulièrement denses, la comparaison avec le plus grand modèle en vaut la peine. Comment les deux s'articulent dans le stack global avec Qdrant figure dans l'aperçu.

Pourquoi l'OCR était la partie bancale de la pipeline

L'OCR a longtemps été le point où des erreurs silencieuses entraient dans la réponse. La voie classique est une chaîne : scanner la page, la convertir en texte par OCR, la découper en morceaux, l'encoder, la récupérer. Chaque étape perd quelque chose. Une page à deux colonnes est mal réassemblée, un tableau se disloque en chiffres sans lien, un diagramme disparaît entièrement, car ce n'est pas du texte. D'après notre expérience, sur les documents difficiles, la plus grande part du problème de qualité ne se situe pas dans le modèle de langage, mais ici, dans la lecture. Le retrieval visuel agit précisément à cette étape : il saute la reconnaissance de texte lors de la recherche et travaille sur l'image de la page.

Les quatre briques, brièvement expliquées

ColPali. La référence, présentée en juillet 2024 (arXiv). Elle s'appuie sur le modèle vision-langage PaliGemma et produit environ 1024 vecteurs d'extraits d'image par page, chacun de dimension 128. Au lieu de comprimer la page en un seul vecteur, la granularité est préservée. La comparaison passe par la Late Interaction, une technique reprise de ColBERT, que nous détaillons ici.

ColQwen. La même recette, une autre base : ColQwen2.5 mise sur Qwen2.5-VL plutôt que PaliGemma et se place le plus souvent en tête sur le benchmark ViDoRe. Qui commence aujourd'hui a intérêt à démarrer ici.

ModernVBERT. Le levier d'efficacité. ColModernVBERT a 250 M de paramètres, soit environ dix fois moins que ColPali, et se situe pourtant selon le papier seulement 0,6 nDCG@5 en dessous. C'est la brique qui rend le retrieval visuel abordable en on-prem.

Qdrant. L'infrastructure sous-jacente. Qdrant stocke nativement les multi-vecteurs de ces modèles et calcule l'évaluation Late Interaction au moment de la recherche (doc). Sans une base vectorielle qui comprend plusieurs vecteurs par page, aucun des trois encodeurs ne fonctionne.

Quand le changement en vaut la peine, et quand non

Le retrieval visuel l'emporte là où la mise en page porte l'information. Contrats scannés, factures, fiches techniques, présentations, formulaires, dossiers multilingues : tout ce sur quoi une chaîne OCR échoue régulièrement. Il épargne en outre toute la maintenance de cette chaîne.

Ce n'est pourtant pas un gain systématique. Plusieurs vecteurs par page coûtent plus de mémoire et plus d'index qu'un seul vecteur de texte, souvent d'un facteur élevé. Pour du texte courant propre et pur, le RAG texte classique reste moins cher et tout à fait suffisant. Et certaines tâches ont finalement besoin de texte, par exemple une recherche en texte intégral, la copie ou une piste de vérification. Pour cela, il reste de bonnes raisons de recourir à l'OCR, en hybride aux côtés du retrieval visuel.

Une feuille de route lucide

1. Tester avec ses propres documents, pas avec le benchmark. ViDoRe est un bon repère, mais votre fonds documentaire ne l'est pas. Prenez les vingt pages sur lesquelles votre recherche actuelle échoue.
2. Démarrer avec ColQwen ou ColModernVBERT, selon le matériel. Sur un GPU restreint, le petit modèle est souvent le plus honnête.
3. Mettre en place Qdrant comme magasin multi-vecteurs, Late Interaction au seul étage de re-ranking, pour garder l'index petit.
4. Calculer le prix du stockage à l'avance. La taille de l'index est l'endroit qui fait mal ensuite, pas le choix du modèle.

Qui cherche l'arc plus large, donc pourquoi modèles locaux et retrieval propre vont ensemble : cela figure dans On-Premise contre cloud. Les briques individuelles, nous les approfondissons dans des textes dédiés, à commencer par le regard PME.

L'écart entre un maillage et une pièce

Un maillage généré et une pièce fabricable sont des objets différents, et l'écart n'est pas cosmétique. Trois contraintes le démontrent. Premièrement, l'impression a besoin d'un solide étanche et manifold (pas de trous, pas de normales inversées, pas d'auto-intersections), et les maillages génératifs violent régulièrement cela ; un slicer ne peut pas faire une pièce d'une surface à trous. Deuxièmement, un maillage est une soupe statique de triangles, alors que la fabrication veut un modèle B-rep paramétrique (un fichier STEP avec esquisses, fonctions et contraintes) qu'un ingénieur peut modifier et qu'un système de FAO peut usiner. Aucun des outils image-vers-maillage ne produit cela.

Troisièmement, et le plus fondamental, une seule image ne porte aucune échelle métrique. Le modèle assigne une caméra supposée et produit une forme sans millimètres garantis, sans épaisseur de paroi imposée, sans tolérances. Et comme une photo ne voit qu'une face, la face cachée n'est pas reconstruite, elle est imaginée : le modèle remplit la géométrie invisible avec une moyenne plausible. Un asset de jeu peut cacher tout cela derrière une belle texture. Une pièce ne le peut pas, car l'imprimante et la charge se moquent de son apparence.

Deux pipelines que le battage confond

La façon la plus claire de planifier est de séparer deux pipelines que le marketing amalgame. Ils servent des pièces différentes et ont besoin d'outils différents.

Le premier pipeline est réel aujourd'hui pour les pièces dont l'ajustement est indulgent. L'IA ébauche la forme ; une personne reste maîtresse de la rendre étanche, de la mettre à l'échelle réelle et d'exécuter un contrôle d'imprimabilité. Le second est là où se trouve la frontière pertinente pour la fabrication : la recherche image-vers-CAO comme CAD-Recode et Img2CAD génère une géométrie paramétrique modifiable, et des outils commerciaux comme Zoo peuvent exporter un vrai fichier STEP, mais ils se limitent largement à des pièces plus simples pour l'instant. Pour une géométrie exigeante, la rétro-ingénierie classique par scan (Geomagic, PolyWorks) reste la voie fiable. C'est le cousin fabrication de la question que nous avons posée sur la reconstruction humaine à image unique : une surface plausible n'est pas la même chose qu'un solide digne de confiance.

Ce qui est réel pour un fabricant de PME aujourd'hui

Face au battage, les vrais gains sont plus discrets et plus précieux que la génération en un coup d'une pièce à partir d'une photo de téléphone. Le coin réel le plus fort est la numérisation de ce que vous avez déjà : des outils comme Theia de Spare Parts 3D et l'analyse de plans de 3YOURMIND transforment d'anciens plans techniques 2D en modèles de pièces de rechange imprimables, annoncés jusqu'à 200 fois plus vite que le redessin manuel, avec un contrôle de fabricabilité attaché. C'est de l'image-vers-3D où l'entrée est un plan d'ingénierie, pas une photo de vacances, et où la géométrie est ancrée dans de vraies dimensions.

Les autres gains solides sont l'accélération de la rétro-ingénierie, où la génération par IA et la retopologie intelligente accélèrent un flux existant par scan plutôt que de le remplacer, et le prototypage rapide de pièces non critiques. Là où elle échoue, c'est exactement là où les enjeux sont les plus élevés : pièces porteuses, à tolérance serrée et réglementées, qui ont besoin d'une échelle, d'une spécification de matériau et d'une traçabilité qu'une seule image ne peut fournir. La règle à retenir est courte. Pour une pièce qui porte du poids ou passe un audit, la face invisible est toujours une supposition, et une supposition est un défaut.

Commencez par le plancher, pas le plafond

Avant toute méthode astucieuse, réglez la base, car elle corrige la plupart des plaintes. Le défaut de production 2026 est la recherche hybride (embeddings denses plus mots-clés BM25) suivie d'un reranker cross-encoder. La recherche hybride capte les correspondances sémantiques et de terme exact ; le reranker re-note un large ensemble de candidats pour ne garder que les quelques passages réellement pertinents, pas juste proches thématiquement. Des guides de praticiens rapportent que cette combinaison élève la qualité de récupération de 15 à 30 pour cent sur des jeux d'évaluation standard.

Cela compte parce que la plupart des échecs réels sont du type simple : la réponse était dans les documents, mais le système ne l'a pas fait remonter. C'est un problème de rappel et de classement, et le plancher ci-dessus le corrige. Prouvez que vous avez besoin de plus avant d'en construire plus. Chaque technique au-delà de ce point ajoute des appels de LLM, de la latence et du coût, donc chacune doit gagner sa place contre un échec mesuré, pas une intuition.

La boîte à outils, indexée par l'échec qu'elle corrige

La façon utile de tenir tout ce zoo de méthodes est d'associer chacune au mode d'échec unique qu'elle traite. Sortez une méthode quand vous voyez son échec, pas avant.

Chaque ligne a une vraie provenance : HyDE vient d'un papier CMU de 2022 sur le retrieval dense zero-shot ; le step-back prompting de Google DeepMind, 2023 ; GraphRAG de Microsoft, 2024. C'est la même discipline de décision-par-échec derrière notre regard sur RAG-Fusion et en quoi il diffère du RAG simple.

La décomposition de requête, spécifiquement

La décomposition de requête scinde une requête complexe en sous-questions indépendantes, récupère pour chacune, puis synthétise une réponse. C'est le bon outil quand une seule passe de récupération ne peut pas fonctionner, parce que les faits vivent dans des documents différents ou qu'un fait dépend d'un autre (qui a réalisé le film qui a remporté un prix donné). La lignée va du prompting du moins-au-plus en 2022 aux moteurs de requête à sous-questions des frameworks d'aujourd'hui.

La partie honnête est qu'elle n'est pas gratuite, et qu'elle peut nuire. Une étude de juillet 2025 de HU Berlin a mesuré la décomposition plus reranking élevant le rappel multi-sauts (Hits@10) de 74,7 à 87,2 pour cent, un vrai gain. La même étude a mesuré le coût : environ 16,7 secondes par requête contre 0,03 seconde pour la récupération naïve, et elle a trouvé que décomposer une requête déjà spécifique introduit du bruit et dégrade la réponse. La décomposition appartient donc aux questions réellement multi-sauts, pas à chaque requête par défaut. Le savoir-faire est de distinguer les deux.

Le levier qui se rentabilise est le routage

Si vous retenez une idée opérationnelle de tout ceci, que ce soit le routage. Classez d'abord la requête, puis ne dépensez de la complexité que là où elle est méritée. Une analyse de 2026 du routage conscient du coût a réduit les tokens facturés de 26 pour cent et la latence moyenne de 34 pour cent à qualité de réponse égale, en n'envoyant qu'environ 18 pour cent des requêtes au retrieval lourd et 14 pour cent à aucun retrieval du tout. Les méthodes coûteuses étaient réservées aux requêtes qui en avaient besoin.

Pour une équipe de PME allemande, c'est une histoire de gouvernance et de coût autant que de qualité. Moins d'appels de LLM, mais justifiés, signifient une dépense prévisible, une latence plus faible, et un système que vous pouvez expliquer à une partie prenante soucieuse de conformité : voici pourquoi cette requête a pris la voie coûteuse, et voici pourquoi celle-là ne l'a pas prise. Un retrieval sur-conçu n'est pas seulement lent, c'est une dépense inexplicable. Le système RAG sophistiqué en 2026 est celui qui sait quand n'utiliser aucune de ses astuces.

Ce que la RPA sait vraiment bien faire

La RPA est basée sur des règles et déterministe. Elle décrit un flux fixe, et il se déroule à chaque fois de la même façon : même entrée, même chemin, même résultat. Pour un processus structuré et stable, par exemple transférer des données d'un formulaire fixe vers un ERP, c'est exactement ce qu'il faut. C'est vérifiable, répétable et bon marché à exploiter. La faiblesse n'apparaît que lorsque quelque chose change : une nouvelle disposition de champ, une entrée inattendue, et la règle rigide casse.

Ce que les agents IA font mieux

Un agent IA entre en jeu là où le flux n'est pas rigide : entrées ambiguës, langage libre, décisions qui ont besoin de contexte. Il peut lire un e-mail non structuré et faire la bonne chose, là où une règle de RPA capitulerait. Le prix est qu'il n'est pas déterministe : la même entrée peut donner deux résultats, et il a besoin d'encadrement, de garde-fous et de contrôle. Jusqu'où portent les agents no-code et où ils s'arrêtent, nous le traitons ailleurs.

La ligne de décision

Une heuristique simple sépare les cas :

• Stable et structuré (formulaire fixe, règle claire, forte répétition) : RPA. La fiabilité bat la flexibilité.
• Ambigu et langagier (textes libres, entrées changeantes, questions de jugement) : agent. La flexibilité bat la rigidité.
• Mixte : souvent la meilleure réponse. La RPA fait la partie fixe, l'agent ne reprend que l'endroit qui exige vraiment du jugement.

Les chiffres du marché appellent à la lucidité : Gartner s'attend à ce que plus de 40 pour cent des projets d'IA agentique soient abandonnés d'ici fin 2027. Beaucoup d'entre eux, parce qu'un agent a été employé là où une règle aurait suffi.

La voie médiane lucide

Pas l'IA ou la RPA, mais le bon niveau pour la bonne partie. L'erreur la plus coûteuse est de confier un flux fiable et réglable à un agent non déterministe, juste parce que l'IA sonne plus moderne. Commencez par la question de la tâche, pas de l'outil. Où l'IA a vraiment sa place dans le stack et via quelle interface, API contre MCP contre CLI le situe.

Ce que fait réellement SAM 3D Body

SAM 3D Body reconstruit un maillage humain corps entier, mains et pieds compris, à partir d'une seule image, en estimant à la fois la pose et la forme. Il introduit un nouveau format de corps paramétrique, le Momentum Human Rig (MHR), qui découple le squelette de la surface des tissus mous, si bien que le rig et la forme du corps peuvent être raisonnés séparément. Comme le reste de la famille Segment Anything, il est promptable : vous pouvez passer des points-clés 2D ou des masques de segmentation pour guider le résultat.

Les spécificités pratiques comptent pour quiconque prévoit de le déployer. Meta a livré des poids ouverts en deux backbones, un DINOv3-H+ à environ 840M de paramètres et un ViT-H à environ 631M, avec le code d'inférence, les données d'entraînement et le modèle MHR. Il rapporte une erreur de maillage 3DPW (MPJPE) de 54,8, et il alimente déjà une fonctionnalité grand public en ligne, View in Room de Facebook Marketplace. Il a été entraîné sur environ 8 millions d'images. Ce n'est pas une démo de recherche ; il est entré en produit dès le premier jour.

Le gain B2B est le pipeline, pas les pixels

Le point stratégique pour une entreprise allemande ou UE est où le calcul s'exécute, pas à quel point le maillage semble astucieux. Une image de corps humain est une donnée personnelle sensible sous le RGPD. Dès l'instant où vous envoyez la photo d'un client à une API de reconstruction tierce, vous avez un contrat de sous-traitance, une question de transfert et un coût de confiance. Les poids ouverts suppriment cette étape : vous exécutez le modèle dans votre propre réseau, et l'image du corps ne sort jamais.

Cela recadre plusieurs cas d'usage de « gênant » à « possédable ». L'essayage virtuel et la visualisation d'ajustement, les avatars AR et VR, l'analyse de fitness et de mouvement, et la prévisualisation pour l'animation ou la production virtuelle peuvent tous s'exécuter sur une infrastructure que vous contrôlez, avec la même UX qu'une API hébergée vous donnerait. C'est la même logique de pipeline possédé que nous avons appliquée à la génération d'assets 3D à partir d'une seule image avec TRELLIS : la valeur n'est pas seulement le modèle, c'est de garder l'entrée sensible de votre côté du mur. La licence est la seule chose à vérifier avant de construire : le rig MHR est confirmé permissif-commercial, et les poids du corps sont livrés sous la SAM Licence, alors lisez les termes réels pour votre usage.

Là où il casse discrètement

Dimensionner correctement le cas d'usage est tout le savoir-faire, car la reconstruction à image unique a des limites honnêtes qu'aucune qualité de modèle ne supprime. Une analyse indépendante a trouvé que SAM 3D Body privilégie une pose plausible sur la précision métrique, et ramènera les corps atypiques (scoliose, changements liés à l'âge, grossesse) vers une moyenne saine. C'est très bien pour un avatar qui doit avoir l'air correct ; c'est faux pour un dimensionnement médical, ergonomique ou légal, où l'écart est le point.

Trois limites de plus à concevoir autour. Une seule image ne peut résoudre ni la profondeur ni l'échelle vraie, si bien que la position globale et les dimensions réelles sont des suppositions sous-contraintes. Une forte occlusion, où l'essentiel du corps est caché, le dégrade fortement. Et il est par image, pas en temps réel : la communauté court déjà à corriger cela avec des variantes plus rapides et des runtimes C++, et la vidéo a besoin de machinerie supplémentaire pour la stabilité temporelle. La règle qui vous garde en sécurité est simple. Dimensionnez le cas d'usage au « plausible » (visualisation, essayage, avatars), pas au « précis » (mesure, diagnostic, sécurité). Dans cette limite, un modèle humain 3D possédé et respectueux de la vie privée est une réelle nouvelle option en 2026.

Où le RAG classique échoue dans les PME

Le RAG transforme vos documents en savoir interrogeable. Le point faible est la première étape : la reconnaissance de texte. Une facture fournisseur avec tableau de postes, un contrat à deux colonnes, une fiche technique scannée avec un plan coté : l'OCR réassemble régulièrement mal ce genre de chose. Le tableau devient un désert de chiffres, les colonnes s'entremêlent, le dessin disparaît. Le modèle reçoit alors déjà du texte cassé et répond en conséquence. D'après notre expérience, sur des dossiers réels, la plus grande part des erreurs se situe ici, bien avant qu'un modèle de langage n'ait seulement voix au chapitre.

Comment la recherche visuelle contourne cela

Les modèles de retrieval visuel sautent la reconnaissance de texte lors de la recherche. Ils décomposent l'image de la page en de nombreux petits extraits, encodent chacun et comparent directement la requête avec eux. Ainsi est préservé le fait qu'un chiffre se trouve dans une cellule de tableau et non dans le texte courant. Trois noms mènent le champ : ColPali comme référence, ColQwen comme variante le plus souvent plus forte sur base Qwen, et ModernVBERT comme petit modèle apte à l'on-prem. Toute la boîte à outils avec la base vectorielle, nous la situons dans l'aperçu du stack. Pour le regard pratique, il suffit de retenir : la page est vue, pas devinée.

Honnête sur les coûts

Le gain n'est pas gratuit. Plusieurs vecteurs par page ont besoin de nettement plus de stockage d'index qu'un seul vecteur de texte. Pour une archive de texte courant pur et propre, le RAG texte classique reste moins cher et suffit. La recherche visuelle vaut la peine là où la mise en page porte l'information, et c'est précisément dans les PME plutôt la règle que l'exception. Et pour les cas où vous avez finalement besoin de texte interrogeable, par exemple pour copier ou pour une piste de vérification, l'OCR reste pertinent, en complément plutôt qu'en remplacement.

Le premier pas est petit

Nul besoin de tout reconstruire pour cela. Prenez les vingt documents sur lesquels votre recherche actuelle échoue, et posez précisément les questions qui se trompent aujourd'hui. Si la recherche visuelle trouve la ligne de tableau que l'OCR a perdue, vous avez votre réponse, sur vos propres dossiers, pas sur un benchmark. Le beau côté : tout le dispositif tourne en local, les données restent dans la maison. Pourquoi cela compte pour les pièces sensibles, c'est dans On-Premise contre cloud.

Pourquoi l'assemblage était le vrai problème

Générer une longue séquence en joignant des clips courts introduit exactement les artefacts qui rendent les rushes inutilisables : raccords visibles entre segments, visages de personnages qui dérivent d'un plan à l'autre, éclairage qui saute. Pour une vidéo de marque ou de produit, cette dérive fait la différence entre un asset utilisable et un faux évident. La durée en une seule passe supprime le raccord, c'est pourquoi 30 secondes natives sont un vrai pas, pas un chiffre de vanité.

Ce que 2.5 change réellement

Trois choses ressortent pour une équipe qui l'utiliserait vraiment :

• Clips natifs de 30 secondes. Une passe, sans assemblage, si bien que la cohérence tient sur toute la durée.
• Jusqu'à 50 références multimodales. Images, audio et vidéo combinés en une génération, environ quatre fois les douze de Seedance 2.0, visant à maintenir un personnage, un produit et un style stables.
• Génération audio-vidéo conjointe. Le visuel et l'audio sont co-traités dans un même espace latent plutôt que générés séparément puis synchronisés après, ce qui maintient le mouvement et le son alignés.

Ensemble, elles visent le même but : la cohérence dans le temps, la chose dont la vidéo professionnelle a besoin et que les clips courts ne pouvaient pas donner.

La réserve honnête

La qualité est désormais la partie facile. Pour un usage professionnel, les questions difficiles décident : pouvez-vous utiliser les rushes commercialement, dont l'image ressemble à qui, où vont les données, et la sortie est-elle assez cohérente pour y apposer une marque. Seedance 2.5 est en bêta entreprise avec un lancement public visé pour début juillet, donc les détails de licence et de provenance sont précisément ce qu'il faut lire avant de s'engager. Le champ plus large, et comment choisir parmi les modèles, se trouve dans notre état de la vidéo IA 2026.

Où il s'intègre

Pour le storyboard, les films de concept et les courts assets sociaux, un clip natif propre de 30 secondes change ce qu'une seule personne peut produire. Pour un travail réglementé ou critique pour la marque, traitez-le comme un moteur de brouillon jusqu'à ce que les droits et la cohérence passent votre seuil. La capacité est réelle ; la gouvernance est la partie à régler d'abord.

La vraie différence, en une ligne chacune

L'ingénierie des prompts, c'est bien formuler une instruction. L'ingénierie du contexte, c'est décider de ce que le modèle voit tout court. Le terme a été popularisé en juin 2025 par Tobi Lutke de Shopify et amplifié par Andrej Karpathy, qui l'a décrit comme l'art de remplir la fenêtre de contexte avec juste la bonne information pour l'étape suivante. La distinction la plus nette vient de Philipp Schmid : le contexte est tout ce que le modèle voit avant de générer une réponse, et c'est un système, pas une chaîne.

Les deux ne sont pas rivaux ; l'ingénierie des prompts est un sous-ensemble. Quand vous écrivez un bon prompt système, c'est de l'ingénierie des prompts. Quand vous décidez quels trois documents récupérer, quels outils exposer, combien d'historique garder, quoi résumer pour l'écarter et quel schéma de sortie exiger, le tout sous un budget de tokens, c'est de l'ingénierie du contexte. Les recommandations d'Anthropic la présentent comme la gestion de tout l'état du contexte à travers les tours, et sa phrase la plus tranchante vaut d'être retenue : le contexte est une ressource finie à rendements marginaux décroissants.

Pourquoi le domaine a basculé, et ce n'était pas la mode

La raison pour laquelle l'ingénierie du contexte est devenue une discipline nommée est que l'hypothèse facile a cassé sous la mesure. L'hypothèse était que les modèles à long contexte permettent de bourrer la fenêtre et d'arrêter de réfléchir. L'étude Context Rot de Chroma a testé 18 modèles de pointe en juillet 2025 et a trouvé que chacun se dégrade à mesure que l'entrée grandit, souvent de façon non uniforme : le modèle ne traite pas le dix-millième token aussi fiablement que le centième. La constatation plus ancienne du « perdu au milieu » pointait dans le même sens.

Deux forces ont fait de la charge, et non du prompt, l'objet à ingénierer. D'abord, les agents, l'usage d'outils, la récupération et la mémoire font que le contexte est assemblé sur de nombreux tours par un système, pas écrit à la main une fois. Ensuite, l'économie : en production chez Manus, le ratio tokens d'entrée sur sortie tourne autour de 100 pour 1, et réutiliser le cache clé-valeur crée une grande différence de coût, si bien que ce que vous mettez dans la fenêtre est une décision de coût autant que de qualité. Plus de contexte n'est pas mieux ; un contexte budgété et pertinent l'est. C'est l'ossature empirique sous notre présentation antérieure de l'ingénierie du contexte et de pourquoi elle compte.

De quoi est réellement faite l'ingénierie du contexte

Dépouillée de l'étiquette, l'ingénierie du contexte est un ensemble de pratiques testables, pas du chuchotement de prompts. Les techniques nommées reviennent chez Anthropic, LangChain et le retour de production de Manus :

• Récupération. Tirer les quelques documents pertinents au moment où ils sont nécessaires, plutôt que de tout coller. C'est la discipline derrière la génération augmentée par récupération.
• Compaction et résumé. Compresser les anciens tours en un résumé courant pour que le budget serve à ce qui est vivant, pas à la transcription.
• Mémoire et prise de notes. Décharger l'état vers des notes ou fichiers externes que l'agent peut relire, au lieu de le porter dans la fenêtre.
• Curation des outils. Garder trois à cinq outils clés chargés et tirer le reste juste à temps. Charger tous les outils dilue le signal et casse le cache.
• Sorties structurées. Exiger un schéma pour que le modèle dépense des tokens sur la réponse, pas sur la mise en forme en prose.
• Isolation. Répartir le travail entre sous-agents pour que chacun ne voie que le contexte dont il a besoin.

LangChain présente le même ensemble comme écrire, sélectionner, compresser et isoler. Le point est que chacun de ceux-ci est mesurable : vous pouvez comparer en A/B un récupérateur, un seuil de compaction ou une composition d'outils, ce qui est précisément ce qui en fait de l'ingénierie plutôt que de la formulation.

Est-ce juste un rebranding ? La réponse honnête

En partie, et c'est bien. Oui, les bons ingénieurs curaient déjà ce que le modèle voit ; la valeur du nom est qu'il oriente l'optimisation vers la charge et le système, pas vers la phrase, là où vivent réellement la fiabilité et le coût. Le débat vivant est plus utile que la querelle terminologique. En juin 2025, Cognition a plaidé contre les systèmes multi-agents, au motif que partager proprement le contexte entre agents est difficile, et a recommandé de garder le travail mono-agent et de partager des traces complètes. La même semaine, Anthropic a décrit un système de recherche multi-agents qui dépend d'une isolation de contexte disciplinée. Même discipline, conclusion architecturale opposée.

Pour une équipe qui construit avec des LLM, les enseignements sont clairs. Budgétez les tokens comme vous budgétez le calcul, car plus n'est pas gratuit et pas toujours mieux. Traitez le travail comme de la plomberie (qualité de récupération, compaction, mémoire, curation des outils, sorties structurées), pas comme de la formulation. Et choisissez votre architecture selon la fiabilité avec laquelle vous pouvez partager le contexte, plutôt que selon l'approche qui sonne le plus avancée. Le nom continuera de muter, certains appellent déjà la couche suivante ingénierie du harnais, mais l'objet est stable : le système qui décide de ce que le modèle a le droit de voir.

Où il aide

Le Vibe Coding brille partout où la vitesse compte et où le code a le droit de disparaître ensuite. Le prototype d'un après-midi, l'outil interne pour une petite équipe, la maquette cliquable pour une présentation client, les premiers 70 pour cent d'une idée : ici, il apporte une vraie valeur. L'exemple d'origine de Karpathy était exactement cela, un logiciel jetable pour un projet de week-end.

La demande le confirme. Des outils comme Cursor, Claude Code, Lovable et Bolt ont grandi en un temps record, Lovable atteignant environ 200 millions de dollars de chiffre d'affaires annuel fin 2025. Dans mon travail aussi, l'utilité est concrète : une personne métier sans bagage de programmation peut faire fonctionner elle-même une idée, au lieu de devoir d'abord la décrire puis d'attendre deux semaines. Tant que le résultat reste une expérience et que personne n'y adosse son activité, c'est un gain de rythme qu'il ne faut pas minimiser.

Où il mord

Dès que le code est livré, le tableau s'inverse, et les preuves sont inconfortablement concrètes. Veracode a examiné en 2025 plus de 80 tâches et plus de 100 modèles : 45 pour cent du code généré contenait une faille de sécurité, et les modèles plus récents ou plus grands ne s'en sortaient pas mieux. Une étude de METR a trouvé que des développeurs expérimentés avec des outils d'IA étaient 19 pour cent plus lents, tout en se croyant plus rapides.

S'y ajoutent les incidents qui marquent les esprits. Un agent Replit a supprimé en juillet 2025 une base de données de production, a ignoré l'instruction explicite de ne rien changer, puis a affirmé qu'une restauration était impossible (elle ne l'était pas). Environ un paquet sur cinq proposé par une IA n'existe pas du tout, et 43 pour cent de ces noms inventés reviennent de façon répétée, ce qui ouvre aux attaquants une nouvelle brèche dans la chaîne d'approvisionnement. Addy Osmani appelle cela le problème des 70 pour cent : l'IA vous amène vite à 70 pour cent, les 30 derniers pour cent faits de cas particuliers, de sécurité et d'intégration restent un travail d'ingénierie classique. Et juridiquement, la situation est nette : la responsabilité du logiciel livré reste à l'entreprise qui le construit et le vend, pas au fournisseur d'IA.

La limite : jetable contre livré

La distinction la plus utile n'en est pas une sur les outils, mais sur l'objectif. Un script qu'une personne utilise une fois est autre chose qu'un logiciel que vos clients, vos auditeurs et le Cyber Resilience Act de l'UE, à partir de décembre 2027, jugeront. Même Gartner, qui table sur 40 pour cent de Vibe Coding dans le logiciel d'entreprise d'ici 2028, qualifie expressément la sortie brute de code jetable, pas prêt pour la production.

Pour les PME, cela signifie : la question n'est pas de savoir si votre équipe a le droit d'utiliser le Vibe Coding, mais pour quoi. Jetable et expérience : volontiers, vite, sans cérémonie. Tout ce qui touche aux données clients, est livré ou doit résister à un contrôle : jamais sans relecture. Ce seul tri épargne la plupart des douleurs ultérieures.

La voie mûre : le Vibe Coding maîtrisé

La bonne nouvelle est que la réponse professionnelle existe déjà en 2025 et 2026, et elle ne s'appelle pas interdiction. Elle s'appelle Vibe Coding maîtrisé, ou développement assisté par IA : l'IA comme un junior très rapide, avec un senior responsable à côté. Voici comment nous l'abordons.

🔸 Spécification avant le prompt. Le contre-mouvement s'appelle Spec-driven Development, avec des outils comme GitHub Spec Kit : d'abord spécification, plan et tâches, puis code. Cela rend le résultat vérifiable plutôt qu'aléatoire.

🔸 Revue et tests avant la production. Aucun code IA ne part en ligne sans relecture. Revue de code, tests automatisés et un scan de sécurité sont la condition, pas le bonus, surtout pour tout ce qui touche aux données ou à l'argent.

🔸 Licence et chaîne d'approvisionnement à l'œil. Du code IA non vérifié peut introduire des bouts sous licence GPL ou des paquets inventés. Les deux appartiennent au processus de contrôle, avant que cela ne devienne un problème de conformité.

Le Vibe Coding est un outil brillant pour la bonne tâche et un risque pour la mauvaise. La différence réside dans le fait de savoir, avant le premier prompt, de quel côté de la limite on se trouve. De quel côté se trouve votre prochain projet ?

Ce que YOLO26 a réellement changé

YOLO26 supprime les deux étapes de post-traitement qui rendaient les détecteurs antérieurs difficiles à déployer. Il exécute par défaut une tête de détection un-à-un, si bien qu'il n'y a pas de suppression non maximale (NMS) à l'inférence et que le réseau produit les détections finales directement. Il abandonne aussi la distribution focal loss (DFL), ce qui allège la tête pour les appareils en périphérie et à faible consommation. La recette d'entraînement est nouvelle aussi : un optimiseur MuSGD, une progressive loss et une affectation d'étiquettes pour petites cibles.

Pourquoi le sans-NMS est la partie à retenir : le NMS est une étape séparée, dépendante des données, qui s'exécute après le réseau, et sa durée varie selon le nombre d'objets à l'image. Le supprimer donne une latence déterministe et un export plus propre, ce qui est exactement ce que l'on veut quand la cible est ONNX, TensorRT, OpenVINO ou CoreML sur du matériel fixe. Moins de boutons de post-traitement signifie moins de façons dont le chemin de production dérive du labo.

Les chiffres sont incrémentaux, pas spectaculaires. Sur COCO, YOLO26n atteint 40,9 de mAP à 2,4M de paramètres, et Ultralytics rapporte jusqu'à 43 pour cent d'inférence CPU ONNX plus rapide que YOLO11n. Ce chiffre CPU, pas la précision, est le titre pour un acheteur qui exécute de la détection sur du silicium de périphérie standard sans GPU.

Les numéros de version ont cessé de signifier ce que vous croyez

La chose la plus utile à comprendre en 2026 est que « YOLO » n'est plus un seul projet, et que les numéros de version viennent d'équipes différentes. Ultralytics maintient YOLO26, YOLO11, et les plus anciens v8 et v5. YOLOv12 et YOLOv13 sont des lignées académiques distinctes, et toutes deux reposent encore sur NMS et DFL, précisément ce que YOLO26 a supprimé.

La leçon est qu'un numéro de version plus élevé n'est pas un produit plus récent du même fournisseur. C'est parfois un groupe de recherche entièrement différent. YOLOv13 a suscité des critiques ouvertes pour avoir rapporté une AP d'environ 54,8 contre 55,2 pour YOLOv12 tout en tournant plus lourdement, une régression présentée comme une amélioration. Et YOLO lui-même n'est pas automatiquement le leader en précision : les détecteurs à base de transformeurs de la famille RF-DETR rivalisent désormais frontalement au sommet. Lisez le benchmark et le mainteneur, pas l'étiquette.

La question de licence qu'un acheteur allemand pose en premier

Avant l'architecture, vérifiez la licence, car celle par défaut contraint la façon dont vous livrez. YOLO d'Ultralytics est sous licence AGPL-3.0. L'AGPL est une licence copyleft forte : si vous distribuez le logiciel, ou l'offrez sur un réseau comme un service, vous êtes généralement tenu de publier l'intégralité du code source correspondant de votre œuvre dérivée, et la lecture courante étend cette obligation aux poids et au code applicatif environnant.

Le point que la plupart des équipes manquent est que l'on-prem ne vous exempte pas. La clause réseau de l'AGPL est déclenchée par l'offre de la fonctionnalité comme un service, même en interne selon certaines interprétations, pas seulement par la livraison d'un binaire à un client. Pour un produit à source fermée, ou un déploiement que vous préféreriez ne pas ouvrir, Ultralytics vend une licence Enterprise commerciale. Elle est sur devis, sans prix public, elle appartient donc tôt à la conversation d'achat, pas après que le prototype fonctionne.

L'enseignement pertinent pour l'achat est simple : budgétez la licence Enterprise, ou choisissez d'emblée un détecteur sous une licence permissive (Apache ou MIT). C'est la même question de contrôle à laquelle nous revenons sans cesse avec les modèles open-weight, où la licence et le stack, pas le benchmark, décident de ce que vous avez le droit de faire.

Comment choisir sans courir après le numéro

Traitez les sorties de 2026 comme une courte checklist ennuyeuse plutôt qu'un classement.

• Figez une version maintenue. Pour la production, la lignée Ultralytics (YOLO26 ou YOLO11) est la voie prise en charge. Les lignées académiques v12 et v13 sont de la recherche, utiles à lire, pas le choix par défaut à livrer.
• Lisez le benchmark, pas l'étiquette. Comparez mAP et latence sur un matériel proche du vôtre, et soyez honnête que RF-DETR ou un modèle plus ancien et plus petit peut l'emporter pour votre scène.
• Testez tôt le chemin d'export. La valeur du sans-NMS se réalise dans l'export ONNX ou TensorRT sur votre appareil cible. Confirmez-la là avant de vous engager.
• Réglez la licence avant le pilote. AGPL ou licence Enterprise, ou une alternative permissive. Décidez-en tant qu'il est encore peu coûteux de changer.

Rien de tout cela n'a besoin du numéro le plus récent. Il faut un détecteur qui tourne à votre latence, sur votre matériel, sous une licence avec laquelle vous pouvez vivre.

La partie honnête vient ensuite. n8n vous décharge du câblage des processus métier, et avec les nœuds d'IA s'ajoute un véritable traitement du langage. Mais dès qu'un modèle de langage entre en jeu, le déroulement cesse d'être déterministe, et c'est précisément là que se joue la question de savoir si une automatisation tient au quotidien. Cet article montre les deux : ce que n8n fait bien, et où passe la frontière avec le vrai développement.

Ce qu'est réellement n8n

n8n est une plateforme d'automatisation de flux de travail basée sur des nœuds. Vous assemblez visuellement un déroulement à partir de nœuds et pouvez, à chaque endroit, ajouter votre propre code en JavaScript ou Python.

🔸 Auto-hébergé ou cloud. Le point décisif pour le Mittelstand : n8n s'exécute comme conteneur Docker sur votre propre infrastructure. Le traitement et les données restent dans votre réseau, l'entreprise demeure le seul responsable de traitement.

🔸 Plus de 400 intégrations plus un nœud HTTP pour n'importe quelle interface REST. Ce qui n'existe pas comme nœud prêt à l'emploi, vous le connectez vous-même.

🔸 Fair-Code, pas de l'open source classique. La Sustainable Use License autorise gratuitement l'usage métier interne. Il est interdit de revendre n8n à des tiers en tant que produit hébergé. Pour un usage propre classique, c'est sans conséquence, mais pour un public technique, il est important de le nommer clairement.

Qui hésite encore à faire tourner l'IA en local trouvera l'arbitrage dans On-Premise contre LLM cloud.

Comment n8n automatise les processus métier

La structure est toujours la même : un déclencheur démarre le déroulement, puis les nœuds s'exécutent étape par étape.

🔸 Déclencheur : webhook, planification, un événement d'application comme un nouvel e-mail ou une nouvelle entrée CRM, un formulaire soumis.
🔸 Nœuds : intégrations d'applications, appels HTTP, requêtes de base de données, logique comme IF et Switch, transformation de données.

En pratique, nous voyons sans cesse les mêmes schémas dans le Mittelstand :

C'est la même logique avec laquelle nous avons construit notre propre micro-application Event Scout, avant de décider ce qui méritait un vrai développement.

Là où l'IA entre en jeu

n8n n'a pas collé l'IA par-dessus, mais l'a intégrée comme une famille de nœuds à part entière, sur la base de LangChain.

🔸 AI Agent Node. Un agent à part entière doté d'appels d'outils, de mémoire et d'une boucle de raisonnement itérative, pas seulement un champ de prompt. L'agent reçoit d'autres nœuds ou workflows comme outils.

🔸 RAG sur ses propres documents. Depuis la version 1.74.0 de janvier 2025, des vector stores comme Qdrant, Weaviate ou pgvector s'intègrent directement comme outil d'agent. Le système répond ainsi sur la base de vos documents, et non à partir des connaissances générales du modèle. Ce qu'est exactement le RAG, nous l'avons expliqué dans Qu'est-ce que le RAG.

🔸 Modèles locaux. Via la connexion Ollama, l'inférence s'exécute sur votre propre matériel. n8n auto-hébergé plus un modèle local donne une stack d'IA entièrement privée, sans transfert vers un pays tiers. Ce que ce matériel coûte de façon réaliste, cela figure dans LLM local en entreprise.

Ce qui fonctionne bien : la classification, l'extraction, le routage, le RAG, les agents simples. Cela devient fragile avec les chaînes d'agents longues et à plusieurs étapes, et avec la reproductibilité des sorties du modèle.

Limites, et quand cela bascule vers l'ingénierie

Quelques points que nous signalons aux clients avant de démarrer :

🔸 Déterminisme et débogage. Une étape d'IA ne fournit pas forcément la même sortie pour une même entrée. Déboguer de longs déroulements d'agents est pénible.
🔸 Versionnement. Les workflows vivent dans la base de données. Une revue propre basée sur Git n'est pas le standard natif, mais relève plutôt des fonctions Enterprise.
🔸 Mise à l'échelle. Le mode serveur unique atteint ses limites face à de nombreux webhooks en parallèle. En production, il faut le mode file d'attente avec des workers séparés.
🔸 Maintenance. Auto-hébergé signifie : mises à jour, correctifs de sécurité, sauvegardes et supervision vous incombent.

Cela bascule vers un vrai développement dès que sont requis une logique déterministe critique pour l'activité, de forts volumes de transactions, des niveaux de service stricts ou un fonctionnement multi-agents en continu. Il faut alors des tests, du CI/CD et de l'observabilité, pas seulement des clics dans l'éditeur. La version de durcissement n8n 2.0 de janvier 2026 a comblé une partie de ces manques, avec une exécution de code isolée et un comportement plus stable sous charge.

Comment nous situons n8n chez iiterate

Nous utilisons volontiers n8n pour exactement ce en quoi il excelle : automatiser rapidement des déroulements internes, greffer l'IA là où elle rend vraiment une étape meilleure, et exploiter le tout en interne, conformément au RGPD.

L'erreur que nous voyons le plus souvent est de confondre un déroulement qui fonctionne avec un système prêt pour la production. Pour des processus internes, à tolérance raisonnable, n8n est souvent toute la réponse. Dès que le processus devient critique pour l'activité, n8n est le moyen le plus rapide de trouver le bon déroulement, et le point à partir duquel nous transposons le chemin éprouvé en développement propre. Là où l'IA a globalement du sens dans le Mittelstand, nous l'avons résumé dans Solutions d'IA pour le Mittelstand.

Le choix ne porte donc pas sur celui qui est meilleur dans l'absolu. Il porte sur la tâche devant vous et la stack que vous faites déjà tourner.

Bien identifier la filiation d'abord

La moitié de la confusion dans cette comparaison vient des noms, il vaut donc la peine de la lever avant toute chose.

🔸 GPT Image 2 est le modèle d'image actuel d'OpenAI, le successeur de la lignée gpt-image, sorti en 2026. L'ancien identifiant d'API gpt-image-1 est la première génération, pas celui-ci.
🔸 Nano Banana Pro est le nom marketing de Google pour Gemini 3 Pro Image, annoncé en novembre 2025 et construit sur Gemini 3 Pro.
🔸 Nano Banana sans le Pro est l'ancien Gemini 2.5 Flash Image, désormais positionné comme le palier rapide et bon marché. Ne confondez pas les deux, car leur qualité de sortie et leur prix diffèrent.

Bien identifier cela importe pour la même raison que la filiation des modèles importait dans la leçon de souveraineté de Fable 5 : vous ne pouvez pas raisonner sur un outil que vous avez mal identifié.

La comparaison qui décide du vrai travail

Les axes qui changent réellement le résultat que vous livrez :

En résumé : Nano Banana Pro l'emporte sur le texte, la résolution et la cohérence. GPT Image 2 l'emporte sur le rendu général et sur l'intégration à un flux OpenAI existant.

Là où chacun l'emporte

🔸 Création marketing avec beaucoup de texte sur image ou des infographies. Nano Banana Pro. Meilleur rendu de texte, sortie 2K et 4K, et ancrage sur la recherche pour des faits et logos exacts. GPT Image 2 est une bonne solution de repli si vous construisez déjà sur OpenAI.
🔸 Cohérence de produit ou de personnage sur une série. Nano Banana Pro. C'est celui doté d'une spécification annoncée, 14 images de référence et 5 personnes cohérentes, ce dont a besoin une campagne cohérente ou une prise de vue produit récurrente.
🔸 Imagerie hero ou éditoriale générale. C'est serré. GPT Image 2 domine actuellement les classements généralistes texte-vers-image, choisissez donc selon la préférence de rendu. Optez pour Nano Banana Pro si vous avez besoin de 4K directement en sortie du modèle.
🔸 Intégration serrée à la stack. Utilisez ce que vous faites déjà tourner. Une boutique OpenAI obtient une seule API et des remises par lot avec GPT Image 2. Une boutique Google ou Vertex obtient une génération native avec Nano Banana Pro.

C'est la même discipline de sélection que nous appliquons aux modèles vidéo d'IA et à l'image-vers-3D avec TRELLIS. Choisissez par la tâche, pas par le logo.

Des limites honnêtes des deux côtés

Aucun des deux modèles n'est exempt de compromis, et ce sont ces compromis qui mordent en production.

🔸 GPT Image 2 plafonne près de 1536 px sur le côté long et n'offre que trois ratios d'aspect, il perd donc sur le grand format et les formes inhabituelles. La tarification au token rend le travail chargé en retouches coûteux, car les retouches facturent aussi les tokens d'entrée image. Le filigrane relève de métadonnées C2PA plutôt que d'une marque invisible intégrée, ce qui vaut la peine d'être confirmé selon vos besoins de conformité.
🔸 Nano Banana Pro porte le filigrane invisible SynthID sur ses sorties, non supprimable en dessous du palier entreprise supérieur. Certains clients le veulent absent, vérifiez-le donc tôt. Il tourne aussi à un coût et une latence plus élevés que le Nano Banana de base, et Google ne publie pas de prix net par image, prévoyez donc le coût via le calculateur Vertex.

Rien de tout cela n'est rédhibitoire. C'est le genre de détail qui décide quel modèle correspond à une contrainte client précise.

Comment nous choisissons chez iiterate

Notre choix par défaut n'est pas la fidélité à un modèle, c'est une courte liste de contrôle. L'image porte-t-elle du texte ou a-t-elle besoin de 4K ? Doit-elle rester cohérente sur toute une série ? Quel cloud le client fait-il déjà tourner ? Y a-t-il des contraintes de filigrane ou de résidence ?

La plupart du temps, ces quatre questions répondent d'elles-mêmes. Le travail chargé en texte, en haute résolution ou critique en cohérence va à Nano Banana Pro. Le travail éditorial général et les pipelines natifs OpenAI vont à GPT Image 2. Nous gardons les deux dans la boîte à outils précisément parce que la bonne réponse change selon le brief.

Les modèles continueront de se dépasser mutuellement, revérifiez donc les classements et la tarification au moment de décider. Ce qui reste stable, c'est l'habitude : faire correspondre le modèle à la tâche, et à la stack dans laquelle le client vit déjà.

Cet article couvre ce qu'est TRELLIS, comment il fonctionne, où il s'insère dans un vrai pipeline d'assets, et les points où il cesse d'être une réponse en un clic.

Ce qu'est TRELLIS

TRELLIS est un modèle génératif 3D qui accepte une image, plusieurs images ou un prompt textuel et produit un asset 3D.

🔸 Latents structurés (SLAT). L'idée centrale est un latent unifié unique qui fusionne une grille de voxels 3D éparse pour la structure avec des caractéristiques visuelles denses pour l'apparence. Le fait de découpler la forme de l'aspect est ce qui permet au même latent de devenir des sorties différentes.
🔸 Trois sorties à partir d'un latent. Champs de radiance, gaussiennes 3D ou un maillage exporté en GLB. Le GLB est la cible pratique, car il transporte les matériaux dans les visionneuses web et AR.
🔸 Ouvert et sous licence MIT. Le cheval de bataille pour l'image, TRELLIS-image-large, compte 1,2 milliard de paramètres. Le modèle et la majeure partie du code sont sous MIT, ce qui compte pour un usage commercial. Une nouvelle ligne de 4 milliards ajoute des matériaux entièrement basés sur la physique, à suivre à mesure qu'elle mûrit.
🔸 Entraîné à grande échelle. Environ 500 000 objets sélectionnés, l'article ayant été retenu comme CVPR 2025 Spotlight.

Cela se place à côté de l'extrémité paramétrique et contrôlable du travail 3D que nous abordons dans Grasshopper pour la conception computationnelle. La 3D générative et la 3D paramétrique résolvent des problèmes différents.

Comment ça fonctionne

Le pipeline est court à décrire et utile à comprendre avant d'y consacrer un GPU.

1. Entrée. Une seule image, plusieurs vues ou un prompt textuel.
2. Latent structuré. Un transformeur à flux rectifié en deux étapes génère d'abord la structure éparse, puis complète les caractéristiques SLAT.
3. Décodage. Le latent se décode dans le format de votre choix : maillage, gaussiennes ou champ de radiance.

En pratique, prévoyez environ 16 Go de VRAM comme plancher, 24 Go étant confortables. La génération s'exécute en moins de deux minutes sur une RTX 4090. Les versions communautaires font baisser les besoins en mémoire, ce qui rend TRELLIS réaliste à héberger soi-même plutôt qu'à louer. Pour les équipes qui pèsent déjà l'inférence locale contre l'inférence hébergée, le même arbitrage que nous avons décrit dans on-premise contre LLM en cloud s'applique aussi aux médias génératifs.

Où il s'insère dans un pipeline d'assets

Le meilleur ajustement se trouve en amont du pipeline, là où la rapidité prime sur la finition.

🔸 Une photo produit ou un prompt vers un GLB. Déposez-le dans une visionneuse three.js ou un model viewer sur le web, convertissez-le en USDZ pour l'AR, ou intégrez-le à une scène de visualisation. Le concept art rapide et les aperçus sont là où TRELLIS brille.
🔸 Édition locale. TRELLIS peut régénérer ou affiner une région du modèle, ce qui est rare parmi les générateurs à image unique.
🔸 Honnête sur la topologie. Le résultat est une géométrie générative, non pas propre au sens d'un artiste. Attendez-vous à des triangles irréguliers, à l'absence de flux d'arêtes propre et à des UV générées automatiquement. Pour le jeu ou le cinéma, vous devrez retopologiser, refaire les UV et rebaker les textures. La nouvelle ligne prenant en compte les matériaux réduit cet écart sans le combler.

Le test de valeur pour un asset donné est donc simple : celui-ci doit-il rendre correctement dans une visionneuse la semaine prochaine, ou doit-il être un asset de jeu riggable et optimisé ? TRELLIS excelle pour le premier et constitue un point de départ pour le second.

TRELLIS face aux alternatives

Le domaine de la 3D, ouverte comme hébergée, a évolué vite. Un repère rapide :

Là où se situe TRELLIS : l'option la plus solide véritablement sous MIT, avec sortie multi-format et édition locale. Des outils hébergés comme Tripo et Rodin le devancent sur une topologie propre prête à l'emploi, et Hunyuan l'emporte souvent sur la texture mais avec une licence plus restrictive. Si votre contrainte est de posséder le modèle et les conditions juridiques, TRELLIS est le point de départ évident.

Les limites honnêtes, et comment nous l'utilisons

Quelques réserves que nous posons sur la table avant que quiconque n'intègre TRELLIS en production :

🔸 La topologie et les UV ne sont pas prêtes à l'emploi pour le jeu ou la CAO. Prévoyez du budget pour la retopologie.
🔸 La CAO est hors périmètre. Les maillages génératifs ne sont pas des solides paramétriques, ce ne sont donc pas des géométries d'ingénierie.
🔸 Le risque lié à l'entrée vous appartient. Le modèle est sous MIT, mais l'exposition juridique de votre image ou de votre prompt d'entrée est la vôtre. N'alimentez pas le modèle avec des photos produit que vous n'êtes pas en droit d'utiliser.

Nous traitons TRELLIS comme un moteur de concept art et de previz : un moyen de mettre un asset 3D crédible sous les yeux d'un client en une après-midi, puis de décider de ce qui mérite un pipeline finalisé à la main. C'est le même instinct que derrière l'usage utile de la vague actuelle des modèles vidéo d'IA, et la même discipline de sélection que nous appliquons pour choisir un modèle d'image. L'outil n'est pas le livrable. C'est le jugement sur l'endroit où il convient qui l'est.

Cet article cartographie les deux versants : ce que ces plateformes font vraiment bien en 2026, et les points précis où vous devez vous attendre à heurter un mur.

Ce qu'est réellement un créateur d'agents no-code

Il est utile de distinguer deux choses vendues sous la même bannière.

L'automatisation de workflow est déterministe. Un déclencheur se déclenche, des étapes fixes s'exécutent, la même entrée donne la même sortie. Les scénarios classiques de Make ou Zapier vivent ici, et beaucoup de travail utile aussi.

Un créateur d'agents no-code laisse un modèle de langage décider du chemin. Vous décrivez un résultat, et le modèle choisit les outils, appelle des API, lit vos documents et boucle jusqu'à ce qu'il estime avoir terminé. Le flux n'est pas câblé à l'avance par vous.

La frontière s'estompe, car les plateformes d'automatisation ont greffé des agents sur leurs canevas tandis que les outils nativement agentiques ont ajouté des intégrations. Pour une équipe du Mittelstand, la vraie question n'est pas « agent ou workflow ». C'est quelle dose de non-déterminisme vous laissez entrer dans un processus métier, et qui détient les données pendant son exécution. Nous avons fait la même distinction en écrivant sur la différence entre une API, un serveur MCP et une CLI.

Ce qu'ils font bien aujourd'hui

Utilisés pour la bonne tâche, ces outils gagnent vite leur place :

🔸 Déclencheurs et intégrations. Webhooks, événements d'applications et planifications à travers des milliers de connecteurs. La plomberie est résolue.

🔸 Appel d'outils. L'agent ne fait pas que discuter, il agit : il interroge une base de données, publie dans un système, ouvre un ticket.

🔸 Retrieval sur vos propres documents. Ancrer les réponses dans le savoir interne tient désormais en quelques clics, le même schéma que celui que nous détaillons dans notre article sur le RAG.

🔸 Flux multi-étapes avec un humain dans la boucle. Un point de validation avant tout ce qui est irréversible.

Le gain, c'est la vitesse. Vous pouvez prouver qu'une idée vaut la peine d'être menée en quelques jours, ce qui est exactement le rôle d'un prototype. Nous avons construit notre propre micro-app Event Scout dans cet esprit avant de décider ce qui méritait une vraie ingénierie.

Où ils s'arrêtent

C'est la partie que la plupart des démos escamotent, et c'est la raison pour laquelle Gartner s'attend à ce que plus de 40 pour cent des projets agentiques soient abandonnés d'ici fin 2027. Le mode de défaillance est rarement un plantage. Il est plus discret que cela.

🔸 Fiabilité et non-déterminisme. La même requête ne donne pas deux fois le même résultat. Les agents ne tombent pas en erreur, ils dérivent : ils bouclent, choisissent le mauvais outil ou agissent sur un contexte périmé. Le coût se manifeste en qualité et en latence, sans aucun voyant rouge sur le tableau de bord.

🔸 Évaluation et observabilité. Les consoles no-code offrent un traçage limité. Mesurer si un agent s'améliore réellement, sur l'ensemble d'une exécution multi-étapes et pas seulement sur la réponse finale, est un ajout que vous devez construire.

🔸 Gouvernance des données et hébergement. La plupart de ces plateformes sont des SaaS américains. Pour des données allemandes, cela signifie des questions de RGPD et de Schrems II que vous ne pouvez pas balayer d'un revers de main. Les options auto-hébergeables qui gardent les données sur vos propres serveurs en UE forment une courte liste : n8n, Flowise, Langflow, Dify. Nous approfondissons cet arbitrage dans On-Premise contre Cloud-LLM et dans ce que le RGPD autorise réellement.

🔸 Coût à l'échelle. La facturation à l'exécution et au crédit pénalise le volume. Sur un modèle à crédits, un même agent peut coûter quelques euros ou plusieurs centaines, uniquement selon la façon dont il a été construit. Les pilotes paraissent bon marché. La production ne l'est souvent pas.

🔸 Verrouillage et transfert. Les canevas propriétaires ne s'exportent pas vers de la vraie ingénierie. Quand vous dépassez un outil no-code, vous reconstruisez d'ordinaire plutôt que de migrer.

La grille de décision

J'utilise cinq questions pour décider si quelque chose reste en no-code ou passe au statut de système construit. Notez chacune bas ou haut.

1. Sensibilité des données. Touche-t-il à des données personnelles ou réglementées ?
2. Courbe de volume et de coût. L'usage grimpe-t-il jusqu'à un point où la facturation au crédit fait mal ?
3. Niveau de fiabilité exigé. Est-ce interne et tolérant, ou tourné vers le client avec un SLA ?
4. Complexité de la logique. Branchements légers, ou logique conditionnelle et à état profonde ?
5. Audit et évaluation. Avez-vous besoin d'évaluations au niveau de la trajectoire et d'une piste d'audit ?

Deux réponses « haut » ou plus, et vous voulez un build sur mesure ou hybride. Sinon, le no-code est le bon outil, surtout pour prouver la valeur.

Le schéma qui fonctionne en pratique n'est pas binaire. Prototypez sur quelque chose comme n8n ou Flowise, trouvez le chemin qui délivre vraiment, puis durcissez ce chemin-là en ingénierie détenue en propre. Le prototype n'a pas été gâché. Il vous a dit exactement quoi construire.

Comment nous les traitons chez iiterate

Nous recourons aux créateurs d'agents no-code tôt et souvent, puis nous sommes délibérés sur le moment de les quitter. Un agent no-code est un moyen rapide et honnête de découvrir si un résultat vaut l'ingénierie qu'il faudrait pour le rendre fiable. C'est une valeur réelle, et pour bon nombre de tâches internes, c'est la réponse entière.

L'erreur que je vois le plus dans le Mittelstand, c'est de prendre une démo qui marche pour un système fini. Ce n'est pas la même chose, et l'écart entre les deux, c'est la liste ci-dessus. Si vous savez où passe la ligne avant de commencer, vous obtenez la vitesse sans le projet abandonné. Si vous voulez une vue posée de la place de l'IA dans une entreprise de taille moyenne au départ, nous l'avons rédigée dans Solutions d'IA pour le Mittelstand.

Deux mises en garde d'emblée pour un acheteur allemand. La tarification des trois change souvent, alors traitez chaque chiffre ici comme daté et à revérifier. Et la résidence des données est une contrainte réelle : aucun d'eux n'héberge dans l'UE par défaut, ce qui compte avant que la moindre donnée personnelle ne touche un appel.

Ce que chacun est vraiment

🔸 ElevenLabs Agents. Construit sur la qualité vocale qui fait la réputation d'ElevenLabs, désormais enveloppée dans une couche d'agent hébergée avec téléphonie via SIP. Le choix lorsque la voix la plus naturelle et le contrôle développeur sont les critères décisifs.

🔸 Retell AI. Une infrastructure d'agents vocaux axée téléphonie. Elle se positionne sur la faible latence et une gestion d'appels fiable, entrants et sortants, et vous laisse apporter votre propre opérateur. Le choix pour des opérations d'appels en production.

🔸 Voiceflow. Une plateforme visuelle et collaborative pour concevoir des agents de chat et vocaux, avec une base de connaissances intégrée. Orientée design et no-code d'abord. Le choix pour une équipe CX ou design qui itère sur des flux. À noter que la voix téléphonique en direct est ici la plus faible des trois, car elle s'appuie sur un fournisseur de téléphonie distinct.

Si votre besoin se rapproche davantage d'un agent textuel ou utilisant des outils que d'une ligne téléphonique, la même logique construire-ou-acheter tirée des outils no-code de création d'agents s'applique.

La comparaison qui compte

Les dimensions qui décident réellement d'un projet d'agent vocal, côte à côte :

Lisez le tableau comme une carte d'arbitrages, pas comme un classement. Aucune colonne n'est la meilleure partout, et c'est tout l'intérêt.

Où chacun trouve sa place

🔸 Une ligne de support allemande qui a besoin de téléphonie et d'une voix allemande naturelle. Commencez par Retell pour une gestion d'appels fiable et le contrôle de l'opérateur, ou par ElevenLabs si le naturel de la voix allemande est le facteur décisif. Pour une souveraineté stricte des données, aucun n'héberge dans l'UE par défaut, alors envisagez un Retell auto-hébergé ou une alternative native de l'UE.

🔸 Une équipe orientée design qui construit un flux CX. Voiceflow. Le constructeur visuel, la collaboration multi-éditeurs et la base de connaissances permettent à une équipe d'itérer sans ingénieurs. Ajoutez la téléphonie séparément lorsque vous avez besoin de la voix.

🔸 Un développeur qui veut une qualité vocale maximale et un contrôle sur mesure. ElevenLabs. Meilleur TTS, contrôle par SDK, agnostique au modèle, SIP pour la téléphonie.

Le schéma est le même que celui que nous appliquons à la plupart des choix d'outils : nommez d'abord le travail, puis choisissez l'outil qui maîtrise ce travail.

La question allemande de la résidence des données

C'est la partie qui décide si un agent vocal est même autorisé, avant que la qualité de la voix n'entre en jeu.

La conformité au RGPD n'est pas la même chose que l'hébergement dans l'UE. Un fournisseur peut être aligné sur le RGPD et pourtant traiter et stocker les appels sur une infrastructure américaine, ce qui rouvre les questions liées à Schrems II. Parmi ces trois : ElevenLabs propose la résidence des données dans l'UE uniquement sur l'offre Enterprise, Retell y parvient via l'auto-hébergement, et Voiceflow est cloud uniquement, sans option de résidence souveraine.

Pour une ligne de support allemande traitant des données clients, cela transforme la présélection en une décision d'hébergement autant qu'en une décision de fonctionnalités. C'est la même logique que nous exposons dans ce que le RGPD autorise réellement et dans on-premise contre LLM cloud : décidez d'abord où les données ont le droit de résider, puis choisissez l'outil qui le respecte.

Comment nous choisirions

Nous ne partirions pas de la marque. Nous partirions de trois questions : cela passe-t-il par le téléphone, qui l'entretient, et où les données ont-elles le droit de résider.

Si c'est une ligne téléphonique, Retell mérite le premier regard. Si la qualité vocale porte l'expérience et qu'un développeur en est propriétaire, ElevenLabs. Si une équipe non technique doit concevoir et posséder le flux, Voiceflow. Et si les données ne peuvent pas quitter l'UE, la conversation se déplace vers l'hébergement avant de se déplacer vers les fonctionnalités, ce qui remodèle souvent la présélection.

La tarification continuera de bouger, alors revérifiez-la au moment de l'évaluation plutôt que de faire confiance à un seul chiffre. La partie durable, c'est l'adéquation, et l'adéquation suit le travail.

Cet article explique pourquoi nous l'avons construit, ce qu'il sait faire, où il s'arrête honnêtement, et se termine par une question ouverte.

L'OBLIGATION, EN BREF ET CORRECTEMENT

La facture électronique n'est plus une option dans le B2B allemand, mais une obligation, et le calendrier est concret.

• Depuis le 1er janvier 2025, toute entreprise nationale doit être capable de recevoir et de traiter des factures électroniques. Sans exception, sans seuil de chiffre d'affaires, y compris les micro-entrepreneurs.
• Jusqu'à fin 2026, le papier ou le PDF restent autorisés à l'envoi, mais le PDF uniquement avec l'accord du destinataire.
• À partir de 2027, les entreprises dont le chiffre d'affaires de l'année précédente dépasse 800 000 euros devront émettre des factures électroniques, à partir de 2028, toutes.

Par facture électronique, on n'entend pas une pièce jointe PDF, mais un format structuré selon la norme européenne EN 16931. ZUGFeRD est la variante courante en Allemagne : un fichier PDF/A-3 avec XML intégré. L'humain voit un PDF lisible, le logiciel lit directement le XML, sans ressaisie ni reconnaissance de caractères. Le graphique ci-dessous montre précisément ces deux vues d'un même fichier.

POURQUOI NOUS N'AVONS PAS SIMPLEMENT PRIS UN ABONNEMENT

Le déclencheur, chacun le connaît : l'obligation arrive, il faut donc un outil. La réponse évidente est un abonnement, et c'est justement là que nous nous sommes arrêtés.

Pour une opération au fond simple, produire un PDF avec XML intégré, les coûts récurrents s'accumulent vite : les outils de facturation courants commencent autour de 10 euros par mois et montent nettement plus haut pour l'envoi de factures électroniques selon les forfaits. Pour une maison qui n'émet que quelques factures par mois, on paie ainsi durablement pour une comptabilité complète que l'on n'utilise même pas.

Mais la vraie raison n'était pas le prix, c'étaient les données. Une facture contient des noms, des adresses et souvent des coordonnées bancaires. La faire transiter par un outil cloud, c'est une sous-traitance selon l'art. 28 du RGPD : un contrat, un tiers, des données qui quittent la maison. En auto-hébergé, tout cela disparaît. C'est la même logique que celle que nous défendons pour les modèles de langage, à lire dans On-Premise contre LLM cloud : garder l'utilité, ne pas céder la souveraineté des données.

CE QUE FAIT CONCRÈTEMENT BELEGT

Belegt est volontairement petit et nettement circonscrit. C'est un générateur, pas un substitut de comptabilité.

Techniquement, c'est une application web que l'on exploite sur son propre ordinateur ou serveur. Les données résident localement dans un fichier, les champs sensibles comme les coordonnées bancaires y étant stockés chiffrés. Il génère des factures ZUGFeRD et Factur-X au profil EN 16931, c'est-à-dire au niveau qui compte juridiquement comme facture électronique à part entière, les valide contre la norme, attribue des numéros de facture continus, gère les profils d'entreprise et de clients, et garde à l'œil les postes ouverts et les analyses.

Les deux choses qui nous font gagner le plus de temps : un déroulé guidé qui produit une facture conforme en quelques étapes, et le fait que le fichier généré apporte immédiatement la vue machine dont le destinataire a besoin. Nous l'utilisons nous-mêmes, chaque mois. C'est la recommandation la plus honnête que nous puissions donner : nous ne l'avons pas construit pour un marché, mais pour nous. C'est l'un de plusieurs petits outils nés ainsi, comme l'outil Event-Scout.

OÙ IL S'ARRÊTE HONNÊTEMENT

Un outil unique auto-hébergé a des limites réelles, et les taire serait exactement le genre de marketing que nous ne faisons pas.

🔸 La norme évolue. EN 16931 et les listes de codes sont régulièrement mises à jour. Un générateur doit être entretenu, sinon il finit par produire des factures non conformes. C'est un travail que quelqu'un doit fournir.
🔸 L'archivage n'est pas inclus. Générer n'est pas la même chose qu'archiver de façon inaltérable. Les GoBD exigent une conservation immuable au format d'origine, désormais pendant huit ans. Un simple générateur ne résout pas cela, cela reste la tâche de l'utilisateur.
🔸 Il ne remplace pas un expert-comptable. Une facture techniquement valide peut néanmoins être incomplète sur le fond. Il n'existe pas de connexion directe au cabinet ou aux systèmes comptables.

En résumé honnête : Belegt comble proprement et sans abonnement la lacune obligatoire de génération et de validation. L'archivage et le flux fiscal restent à l'extérieur. Qui le confond avec une suite complète sera déçu. Qui a précisément cette lacune obtient un outil sans ballast.

DEVONS-NOUS LE PARTAGER, ET COMMENT ?

Ici, l'article se termine volontairement par une question plutôt qu'une réponse, car nous ne le savons pas nous-mêmes encore.

Il y a deux voies plausibles. La première : nous publions Belegt, comme solution auto-hébergée que toute petite entreprise peut faire tourner sur sa propre machine, sans abonnement et avec les données chez elle. La seconde : nous proposons une variante maintenue, que nous tenons à jour, pour laquelle nous aidons à l'installation et répondons des mises à jour de la norme, contre une contribution équitable. Les deux ont leur logique, et la charge de maintenance de la section précédente est précisément la raison pour laquelle la réponse n'est pas triviale.

D'où cette demande honnête : si un outil ZUGFeRD local, conforme à la protection des données et sans abonnement vous serait utile, à vous ou à votre entreprise, écrivez-nous. Vous suffirait-il de l'exploiter vous-même, ou préféreriez-vous une version accompagnée ? C'est précisément ce signal qui nous aide à décider si quelque chose que nous avons construit pour nous doit devenir quelque chose que nous partageons.

Claude Code, Codex, Cursor, Antigravity et Opencode résolvent la même tâche de manières très différentes. La seule question qui divise le champ est simple : votre code a-t-il le droit de quitter la maison ? Qui peut y répondre par oui choisit selon le stack. Qui ne le peut pas n'a qu'une seule option sérieuse. Ce texte classe les cinq selon cette question et se termine par la décision que je recommande à une équipe allemande.

CINQ OUTILS, UNE PREMIÈRE QUESTION

Les cinq se situent à des niveaux différents, et le facteur de forme dit déjà beaucoup de l'usage.

• Claude Code est un agent de terminal d'Anthropic : fort sur les modifications multi-fichiers, le grand contexte et une boucle agentique dans le terminal.
• Codex d'OpenAI existe en CLI, sandbox cloud et intégration IDE à partir d'une fenêtre d'usage commune.
• Cursor est l'IDE IA avec mode agent et agents en arrière-plan, et un choix de modèle libre.
• Antigravity est l'IDE centré sur l'agent de Google, disponible depuis le 20.11.2025, avec une interface de gestion pour lancer et observer des agents parallèles (Google).
• Opencode est un agent de terminal open source sous licence MIT, indépendant du modèle via de nombreux fournisseurs et des points de terminaison auto-hébergés (opencode.ai).

Comment ces outils s'insèrent dans un stack, de l'API à la CLI, nous l'avons exposé dans API, MCP ou CLI. Ici, il s'agit du choix, et il commence par la situation des données.

VOTRE CODE QUITTE-T-IL LA MAISON ?

Cette seule question trie le champ plus vite que n'importe quelle liste de fonctions, car elle décide de la conformité et de la confidentialité avant qu'aucune fonctionnalité ne compte.

Quatre des cinq envoient le code vers un cloud tiers. Claude Code, Codex, Cursor et Antigravity tournent contre des modèles hébergés aux États-Unis. Ce n'est pas en soi rédhibitoire : pour de nombreux projets, c'est acceptable, et en tarif entreprise on peut négocier des clauses Zero-Data-Retention et No-Train. Mais le code sort, et il faut l'accepter consciemment, pas le négliger.

Opencode est l'exception. Parce qu'il est indépendant du modèle et peut s'adresser à un point de terminaison local, il tourne entièrement contre un modèle auto-hébergé. Le code ne quitte alors jamais la maison. C'est exactement la ligne de partage qui décide de tout le reste. Quel modèle open-weight vous placez derrière est une décision à part, que nous parcourons dans Modèle open-weight pour le B2B allemand.

SI LE CLOUD EST ACCEPTABLE : CHOISIR SELON LE STACK

Si vous acceptez sciemment le cloud hébergé, alors c'est le stack qui décide, pas le benchmark. Une carte succincte :

La règle pragmatique : une maison Anthropic prend Claude Code, une maison OpenAI prend Codex, une équipe centrée sur l'IDE prend Cursor ou Antigravity. Des chiffres de benchmark comme des scores SWE-Bench autour de 85 pour cent circulent, mais ce sont le plus souvent des données de fournisseurs, rarement vérifiées de façon indépendante ; je ne fonderais aucun choix d'outil là-dessus. Ce qu'un agent de code apporte au-delà du pur développement, notre article Claude Code au-delà de l'ingénierie le montre.

SI LE CODE DOIT RESTER DANS LA MAISON : OPENCODE PLUS SON PROPRE MODÈLE

Si le code ne peut pas sortir, il reste une option sérieuse, et elle est bonne.

Opencode est open source sous MIT, parle à de nombreux fournisseurs et, surtout, à un point de terminaison local. Couplé à un modèle open-weight auto-hébergé, on obtient un agent de code où ni le code source ni les prompts ne quittent votre propre infrastructure. Pour des données réglementées, le secret professionnel ou tout simplement des clients prudents, c'est souvent la seule architecture viable. Un modèle de code ouvert comme Kimi K2.7, nous l'avons examiné spécialement à cet effet.

Le prix de ce contrôle est un travail propre : vous assemblez vous-mêmes le modèle, le matériel et l'exploitation, il n'y a pas de flotte d'agents cloud gérée. En pratique, il aide de donner de la structure à l'agent, par exemple une carte de la base de code, comme nous l'avons décrite dans Graphify. L'effort est réel, mais il achète quelque chose que les outils hébergés ne peuvent pas offrir.

COMMENT JE DÉCIDE

Vous n'avez pas besoin d'une réponse unique pour toute l'entreprise, mais de la bonne selon la situation des données. Voici comment je procède :

1. Clarifier la situation des données. Le code concerné a-t-il le droit d'aller dans un cloud américain ? Cette réponse vient du droit et du client, pas de l'équipe de développement.
2. Si oui, choisir selon le stack. Maison Anthropic vers Claude Code, maison OpenAI vers Codex, équipe IDE vers Cursor ou Antigravity, chacune avec des conditions ZDR et No-Train négociées.
3. Si non, Opencode plus son propre modèle. La seule option où le code ne quitte pas la maison.
4. Garder la dépendance à l'œil. Chaque outil exige son propre attachement, alors gardez ouverte une voie de retour vers un niveau plus profond, au cas où un fournisseur change les conditions.

Nous-mêmes travaillons selon les projets avec plusieurs de ces outils, et c'est précisément le point : le choix est lié au projet, pas à une idéologie. Le petit outil interne que nous avons construit avec un agent plutôt que de le commander figure dans Construire event-scout. Lesquels de vos dépôts n'auraient en réalité pas le droit d'aller dans un cloud tiers aujourd'hui, et quel outil utilisez-vous pourtant pour cela ?

Voici la carte de cette surface, à quoi sert chaque élément, et où se trouvent les arêtes vives.

CINQ FAÇONS D'ÉTENDRE, UN SEUL PRINCIPE

Sous les noms, chaque point d'extension fait la même chose : il déplace le savoir-faire hors du prompt vers des fichiers versionnés que l'agent charge quand il en a besoin.

• Les Skills sont des dossiers d'instructions, de scripts et de ressources. Une courte description reste dans le contexte ; le skill complet ne se charge que lorsque l'agent le juge pertinent. C'est la divulgation progressive : peu coûteux à conserver, détaillé quand il est invoqué.
• Les commandes slash sont des raccourcis nommés qui se déploient en un prompt fixe. La façon simple d'encoder une fois une demande répétée et de la réutiliser.
• Les hooks sont des commandes shell déclenchées à des événements du cycle de vie : démarrage de session, avant un appel d'outil, après, à l'arrêt. Un hook pré-outil peut inspecter et bloquer un appel avant son exécution.
• Les connecteurs MCP donnent à l'agent un accès authentifié à des systèmes qu'il ne pourrait pas atteindre autrement : une base de données, un suivi de tickets, une API interne. Chaque serveur porte ses propres identifiants.
• Les sous-agents sont des instances d'agent distinctes créées pour une sous-tâche ciblée, avec leur propre contexte et leurs propres instructions.

Un plugin regroupe l'un ou l'autre de ces éléments en une unité installable. Le principe sous tout cela : encodez votre savoir-faire en fichiers dans votre dépôt, pas en habitudes dans la tête d'une seule personne. Nous avons exposé la version intégration système de ce choix dans API, MCP ou CLI.

SKILLS ET MCP NE SONT PAS RIVAUX

La question la plus courante en ce moment est « Skills ou MCP », et la réponse honnête est qu'ils résolvent des problèmes différents.

MCP, c'est l'accès : il connecte l'agent à un système qu'il ne peut atteindre seul, avec identifiants et état. Les Skills, c'est le savoir-faire : une expertise répétable que l'agent applique à des systèmes dont il dispose déjà. L'analogie qui circule est juste : MCP, ce sont les rayons du magasin de bricolage, les Skills, c'est l'employé expérimenté qui sait vers quel rayon marcher.

L'économie des tokens décide de la forme d'une bonne configuration. Un Skill coûte quelques dizaines de tokens tant qu'il n'est pas invoqué. Une poignée de serveurs MCP peut coûter des dizaines de milliers de tokens de contexte avant la première tâche, car chaque serveur annonce tous ses outils d'emblée. Aussi le schéma de travail vers lequel convergent la plupart des praticiens est-il de nombreux Skills légers et peu de connecteurs bien choisis, pas un tas où tout est installé. La démo ci-dessous parcourt les cinq types d'extension et le coût comme le risque que chacun porte.

POURQUOI LE STANDARD OUVERT COMPTE POUR LA SOUVERAINETÉ

Le changement récent le plus utile est que la couche d'extension a cessé d'être la fonctionnalité d'un seul fournisseur.

Les Agent Skills ont été publiés comme standard ouvert en décembre 2025, et le format a été repris chez plusieurs fournisseurs d'agents en quelques semaines. En pratique, cela signifie qu'un skill écrit pour un harnais n'y est pas prisonnier. Pour une entreprise allemande qui pèse le risque du « verrouillage sur un seul fournisseur américain », c'est une réponse partielle à la couche que vous contrôlez : le savoir-faire que vous encodez est portable, même quand le modèle sous-jacent est loué.

Associez cela à des connecteurs pointés vers des systèmes hébergés en UE ou on-premise, et l'histoire de la résidence des données tient en même temps que l'histoire des capacités. Le savoir-faire est vôtre et portable ; les données restent où elles doivent. C'est une position plus durable que de parier le flux de travail sur la feuille de route d'un fournisseur, le même raisonnement que derrière le fait de choisir un agent de code sur le harnais, pas sur le modèle.

CHAQUE POINT D'EXTENSION EST UNE SURFACE D'ATTAQUE

La même puissance qui rend le harnais utile le rend dangereux, et les risques sont récents et documentés, pas hypothétiques.

Les hooks exécutent du shell arbitraire, ce qui est exactement une surface d'exécution. Check Point a divulgué CVE-2025-59536 en février 2026 : un fichier de configuration malveillant dans un dépôt cloné pouvait exécuter des hooks avant même que la boîte de dialogue de confiance n'apparaisse. Un problème connexe, CVE-2026-21852, couvrait l'exfiltration de clés API via un remplacement de variable d'environnement. MCP apporte son propre problème de chaîne d'approvisionnement : chaque serveur détient des identifiants, et des scans ont trouvé des centaines de serveurs MCP exposés à Internet sans authentification. Et les places de marché de skills recensent désormais des milliers de skills communautaires, faciles à installer et difficiles à auditer, avec des signalements de skills franchement malveillants en circulation.

Rien de tout cela n'est une raison d'éviter d'étendre le harnais. C'est la raison de l'étendre délibérément.

GOUVERNEZ LE CATALOGUE, NE COLLECTIONNEZ PAS LES PLUGINS

La discipline qui sépare une configuration de production d'une expérience de laboratoire est un catalogue relu et sur liste blanche : un ensemble connu de skills, hooks et connecteurs que quelqu'un a lu, avec une porte de confiance avant que quoi que ce soit de nouveau ne le rejoigne.

C'est sans gloire et c'est tout l'enjeu. Quels hooks peuvent exécuter du shell. Quels serveurs MCP détiennent quels identifiants. Quels skills sont approuvés, et qui les a approuvés. Pour une équipe de PME, c'est là que le savoir institutionnel devient un outillage durable qui survit au renouvellement du personnel, et là où le travail cesse d'être la config astucieuse d'un ingénieur pour devenir quelque chose que l'entreprise possède. Quand nous avons construit notre propre outil de veille interne comme une petite app agentique, la valeur n'était pas l'astuce, c'était que le processus était désormais un fichier relu dans un dépôt plutôt qu'un souvenir. Nous l'avons raconté dans construire une petite micro-app agentique.

Le modèle, vous pourrez le remplacer au prochain trimestre. Le catalogue d'extensions est l'actif que vous conservez. Aussi la question qui vaut d'être posée avant d'installer le prochain plugin est-elle simple : qui l'a relu, et à quoi peut-il toucher ?

Cet article est un aperçu lucide : les cas d'usage qui tiennent, les aides qui existent vraiment en RLP, et l'unique obstacle qui freine presque tout.

QUELLES SOLUTIONS D'IA TIENNENT VRAIMENT

Les solutions qui font leurs preuves dans les PME sont peu spectaculaires et proches des processus existants. Elles font gagner du temps, elles créent rarement du nouveau chiffre d'affaires.

🔸 Intelligence documentaire. Lire et classer automatiquement factures, bons de livraison, contrats et e-mails. La barrière d'entrée la plus basse, un effet perceptible rapidement.
🔸 Gestion des connaissances par RAG. Une source de renseignements propre à l'entreprise sur son fonds documentaire interne : manuels, documentation de processus, offres, historique de service. Elle allège l'intégration et le support, et le savoir ne se perd pas lors d'un départ.
🔸 Automatisation des offres et des factures. Produire textes d'offres et calculs à partir de dossiers, organiser les flux de facturation. Avec l'obligation de facturation électronique, c'est de toute façon à l'ordre du jour.
🔸 Agents de service sur son propre savoir. Support de premier niveau et FAQ, ancrés sur les données de l'entreprise plutôt que sur un chatbot cloud généraliste.
🔸 LLM local pour données sensibles. Traiter localement ou en hébergement allemand les données du personnel, de mandants, de conception ou de patients.

L'appréciation lucide : dans les PME, l'IA joue surtout sur l'efficacité, rarement directement sur le chiffre d'affaires. Qui ne choisit pas proprement le cas d'usage brûle du budget, d'autant que les dépenses d'innovation tendent plutôt à baisser.

LE PAYSAGE DES AIDES EN RLP, SANS LES MYTHES

Avant de parler d'aides, un travail de nettoyage : beaucoup de programmes qui circulent sont morts ou n'ont jamais été de RLP. DigiBoost RLP est fermé depuis 2022, le programme fédéral go-digital s'est éteint fin 2024, et le chèque numérisation de 20 000 euros souvent cité relève de la Rhénanie-du-Nord-Westphalie, pas de RLP.

Ce qui fonctionne vraiment en 2025 et 2026 :

• Programme de conseil aux entreprises RLP. Depuis décembre 2025, subvention notamment à la numérisation et à l'intelligence artificielle. Il remplace l'ancien BITT.
• IBI-FEDER Rhénanie-Palatinat. Subvention pour l'innovation et la numérisation en entreprise, pour les PME établies en RLP.
• Chèque innovation RLP. Jusqu'à 20 000 euros non remboursables pour des travaux de recherche et développement confiés à des structures externes.
• Centre Mittelstand-Digital de Kaiserslautern. Conseil gratuit et neutre à l'égard des fournisseurs, ateliers et démonstrateurs.

Les aides sont donc là. Elles ne remplacent simplement pas la décision de ce que l'on veut réellement construire. C'est précisément là qu'aide la sélection dans le graphique ci-dessous.

LE VRAI OBSTACLE EST LA PROTECTION DES DONNÉES, PAS LA TECHNIQUE

Quand des projets d'IA échouent dans les PME, c'est rarement à cause du modèle. Ils échouent sur la question de savoir où les données ont le droit de résider.

77 pour cent des entreprises citent la protection des données comme premier obstacle, devant la pénurie de main-d'œuvre qualifiée à 70 pour cent. Dans le même temps, 73 pour cent autorisent leurs salariés à utiliser des modèles de langage, mais seulement 23 pour cent les restreignent à des modèles propres à l'entreprise. En clair : environ la moitié laisse tourner sans contrôle des modèles cloud librement accessibles. Ce n'est pas de la numérisation, c'est de l'IA fantôme, une fuite de données annoncée.

S'y ajoutent un manque de maturité des données, près d'un quart n'a pas de données adaptées, et un scepticisme fondé sur le ROI. L'écart n'est pas l'IA oui ou non. Il se situe entre l'usage informel et un cadre sûr et productif.

SOUVERAIN NE VEUT PAS DIRE PLUS CHER, MAIS PILOTABLE

La réponse à l'obstacle de la protection des données n'est pas de renoncer à l'IA. Elle est d'aligner le lieu d'exécution sur la sensibilité des données, pas sur le marketing.

Pour des tâches non critiques, un modèle cloud est défendable. Dès que des données personnelles, confidentielles ou stratégiques sont en jeu, le traitement doit se faire dans un environnement allemand ou UE, ou sur son propre matériel. Le RAG sur son propre fonds, en local ou hébergé en Allemagne, donne l'utilité d'un modèle de langage sans envoyer le contenu hors de la maison à chaque requête. Quand l'IA locale se justifie par rapport au cloud, nous le situons dans On-Premise contre LLM cloud, et comment le RAG fonctionne techniquement dans Qu'est-ce que le RAG.

Restons honnêtes : toutes les solutions ne doivent pas être on-premise. L'art est dans l'affectation, et c'est précisément ce qu'aucun outil ni aucune notification d'aide ne fait à votre place.

UN PREMIER PAS RÉALISTE

La voie praticable est lucide et par étapes, pas la grande promesse d'IA d'un coup.

Prioriser un cas d'usage dont dépendent du temps ou des erreurs. Vérifier le socle de données, car le RAG sur un fonds chaotique ne fournit aucune valeur. Construire un petit pilote avec une mesure de succès claire. Puis seulement passer à l'échelle. Ces étapes peuvent être cofinancées via le programme de conseil aux entreprises RLP ou le chèque innovation, et accompagnées gratuitement par le centre Mittelstand-Digital. Nous avons décrit le déroulé complet dans la feuille de route pratique de l'IA.

Chez iiterate, nous sommes à Coblence et à Remagen et réunissons précisément ces trois choses : stratégie, construction et conformité. Les PME de RLP s'y mettent déjà. La tâche est de faire de l'essai informel quelque chose de souverain et de robuste. Par quoi commenceriez-vous, et où se trouvent vos données les plus sensibles ?

Veo, Kling et Seedance livrent des clips impressionnants, mais ils sont fermés et hébergés. Wan Animate d'Alibaba est le seul modèle ouvert de la série, et donc le levier intéressant pour qui ne veut pas se dessaisir de son matériel. Ce texte classe les quatre pour une entreprise allemande qui construit des démos produit et des vidéos marketing, et prend au sérieux la régulation qui se durcit en août.

L'AUDIO EST DEVENU STANDARD, LA QUALITÉ EST DEVENUE UN DÛ

Le changement le plus important de l'année est que la qualité visible n'est plus une avance, mais une mise de départ.

Le son natif est devenu standard. Veo 3 a apporté l'audio généré en synchrone, et début 2026 Kling 2.6 et Seedance 2.0 de ByteDance généraient aussi dialogue et bruitages en une passe. Les modèles muets paraissent désormais dépassés pour un travail de démo. En même temps, les clips restent courts : huit secondes en natif sont typiques, Seedance 2.0 atteint environ quinze, les pièces plus longues naissent par assemblage, pas d'un seul jet.

Des laboratoires chinois dominent plusieurs classements. Seedance était en tête des comparatifs indépendants texte-vers-vidéo en juin 2025, devant Veo 3 et Kling (arXiv). De telles places changent tous les mois. C'est précisément la raison de ne pas fixer le choix sur le classement, mais sur les trois critères qui restent stables.

LES QUATRE EN APERÇU

Une précision importante sur les noms d'abord : chez ByteDance, Seedream est le modèle d'image et Seedance le modèle vidéo. Ici, il s'agit de Seedance.

• Veo 3.1 (Google, fermé). Meilleure fidélité au prompt, son synchrone 48 kHz, l'intégration la plus profonde dans une pipeline via Vertex AI et Flow. Hébergé, la sortie porte le filigrane SynthID de Google.
• Kling 2.6 (Kuaishou, fermé). Fort en image-vers-vidéo et bon mouvement, avec son natif depuis la version 2.6, jusqu'à une dizaine de secondes. Accessible via API avec conservation des données à Singapour.
• Seedance 2.0 (ByteDance, fermé). Clips plus longs jusqu'à environ quinze secondes et planification de caméra. Accompagné d'une question juridique ouverte, après que Disney a envoyé une mise en demeure en février 2026, ce qui constitue un risque réel pour un usage commercial.
• Wan Animate (Alibaba, ouvert). Publié sous Apache 2.0 et auto-hébergeable, spécialisé dans l'animation de personnages, le transfert de mouvement et le remplacement de personnage à partir d'une image de référence (Hugging Face). Moins de finition et des clips plus courts que les hébergés, mais un contrôle total.

Runway, Sora 2 d'OpenAI et MiniMax remplissent encore le champ, mais sont de même nature au regard de la question décisive ici : puissants, mais fermés.

L'OBLIGATION D'ÉTIQUETAGE ARRIVE LE 2 AOÛT

La régulation est le véritable événement de 2026, pas le prochain modèle. Qui emploie la vidéo IA en usage commercial doit régler l'étiquetage au préalable.

Les obligations de transparence de l'article 50 du règlement européen sur l'IA deviennent applicables à partir du 2 août 2026 (EU AI Act). Les médias synthétiques doivent être marqués de façon lisible par machine et les deepfakes signalés. Concrètement : la provenance est une fonction de conformité, pas un extra agréable. Les modèles hébergés l'apportent en partie, Google par exemple via SynthID, d'autres via des preuves de contenu C2PA. Wan auto-hébergé ne porte en revanche aucun filigrane imposé, l'étiquetage est alors entre vos mains, comme une étape propre et documentée de la pipeline.

Quels contenus IA relèvent du règlement et ce qui doit être mis en œuvre et quand, nous l'avons exposé dans EU AI Act 2026 et dans le cadre de RGPD et IA.

LE MODÈLE OUVERT EST LE LEVIER

Si le matériel n'a pas le droit de quitter la maison, le modèle ouvert est la vraie réponse, pas le plus beau.

Wan dans les versions 2.1 à 2.2 et Wan Animate sont en permanence sous Apache 2.0, donc plein usage commercial, redistribution et fine-tuning sans appel à la maison mère. La variante plus petite tourne sur une seule carte de 24 Go, la variante 14B a besoin d'environ 80 Go. Auto-hébergé sur une infrastructure européenne, au besoin cloisonnée, aucun rush ne quitte votre contrôle, et il n'y a pas de conditions d'utilisation tierces ni de dépendance géopolitique. Le prix est moins de finition et des clips plus courts que Veo ou Seedance, ce que l'on accepte sciemment pour la souveraineté.

C'est la même logique que nous suivons pour les modèles de langage : un modèle ouvert et contrôlé bat les derniers pourcents de qualité quand le contrôle est l'enjeu (IA européenne souveraine). Pour les modèles du monde aussi, la même voie ouverte se dessine (NVIDIA Cosmos 3).

COMMENT JE DÉCIDE POUR UN PROJET DE DÉMO

La décision suit la situation des données et l'objectif, pas le plus beau démoreel. Voici comment je procède :

1. Matériel sensible ou réglementé. Si la vidéo montre des produits avant leur lancement, des clients ou de l'interne, alors Wan auto-hébergé sur une infrastructure UE, et l'étiquetage comme étape propre de la pipeline.
2. Marketing public, contenu non critique, finition décisive. Alors un modèle hébergé comme Veo ou Seedance, mais avec des conditions choisies sciemment et une provenance clarifiée.
3. Dans tous les cas, régler l'étiquetage avant le 2 août, pas après.

Dans notre propre travail créatif, nous mélangeons cela selon les projets, et le point n'est pas de sacrer un modèle vainqueur. Le point est que la qualité visible est devenue la partie facile et que les questions difficiles, situation des données, droits et étiquetage, décident de l'usage. Laquelle de vos vidéos prévues pourriez-vous seulement confier à un service américain hébergé, et laquelle relève de votre propre infrastructure ?

Qwen, Kimi, Nemotron et Minimax sont tous sérieusement utilisables en 2026. Mais seuls trois des quatre portent une licence réellement libre, une seule famille tient proprement sur du matériel de PME, et aucun fournisseur ne publie une comparaison propre de ces quatre-là en allemand. Ce texte classe les quatre selon les critères qu'un acheteur doit réellement vérifier, et se termine par la décision que je recommande à une PME.

D'abord la licence, ensuite le benchmark

La licence est la première porte, car elle décide de tout usage commercial on-prem avant qu'un seul benchmark ne compte.

Trois des quatre sont ici sans complication. Qwen3 est sous Apache 2.0, Minimax M2 sous MIT, Kimi K2 sous une licence MIT modifiée (Hugging Face). Ce sont de vraies concessions libres : usage commercial, redistribution, fine-tuning, sans appel à la maison mère.

🔸 Nemotron est le cas particulier.
L'Open Model License de NVIDIA n'est pas une pure licence Apache ou MIT. Elle lie l'usage aux conditions de NVIDIA et prend fin automatiquement si l'on retire les mécanismes de protection intégrés (NVIDIA). Le modèle est bon, mais cette clause atterrit d'abord au service juridique, pas chez l'ingénierie. Nous avons décrit l'approche NVIDIA en détail dans l'article sur Nemotron 3.

Qui utilise la souveraineté comme argument devrait savoir lire la licence comme un contrat, car c'est exactement ce qu'elle est.

L'allemand est-il vraiment bon ?

La réponse honnête : il n'existe pas de comparaison propre à quatre voies de ces modèles en allemand, il faut donc la produire soi-même.

Une infrastructure d'évaluation allemande existe. SuperGLEBer, le leaderboard Occiglot Euro-LLM et MMLU-ProX sur 29 langues couvrent l'allemand (ACL Anthology). Ce qui manque, c'est une comparaison publiée en tête-à-tête de ces quatre-là sur du texte allemand. Qwen3 a été entraîné sur 119 langues et est la famille au multilinguisme le plus largement attesté (Qwen) ; pour Kimi, Nemotron et Minimax, les fournisseurs ne citent pas l'allemand comme point fort particulier.

La conséquence pratique est inconfortable mais claire : les places de benchmark sur des tests anglais disent peu de chose sur la qualité de vos contrats, offres ou textes de support allemands. Le seul test fiable est celui sur votre propre matériel. Comment lire les classements sans se laisser tromper, cela figure dans l'article sur le modèle local.

Ce qui tourne sur votre matériel

L'adéquation au matériel trie le champ plus vite que tout benchmark, car un modèle qui ne tient pas sur vos cartes est simplement éliminé.

Qwen3 est ici l'exception. Les variantes denses de 4B à 32B tournent quantisées sur un à deux GPU, et la variante 30B-A3B-MoE fournit une qualité de modèle avec seulement environ 3B de charge de calcul active. C'est le format qui convient à une box on-prem typique de PME.

Kimi K2 et Minimax M2 sont des modèles MoE de niveau frontière. Minimax n'active certes que 10B de paramètres, mais les poids complets exigent un serveur multi-GPU ; Kimi, avec 1 billion de paramètres au total, plus encore. Nemotron 3 Nano, avec 3,6B de paramètres actifs, est très sobre et tourne sur une carte, mais recule à cause de la licence. Ce que cette réalité de VRAM coûte concrètement, nous l'avons calculé dans l'article matériel.

La géopolitique est dans les poids, pas dans l'API

Avec les modèles open-weight, la question de la souveraineté se déplace : les poids tournent entièrement hors ligne, il n'y a donc pas d'interrupteur d'arrêt distant. Ce qui reste, c'est ce qui est cuit dans le modèle.

Trois des quatre laboratoires sont chinois (Qwen, Kimi, Minimax), un est américain (Nemotron). Comme les poids tournent en local, la vraie question n'est pas l'emplacement du serveur, mais l'orientation dans le modèle lui-même. Des tests indépendants rapportent des taux de refus élevés des modèles chinois sur des sujets politiquement sensibles, plus fort en langue chinoise et plus faible mais présent en allemand (ChinaBench). Ces chiffres sont auto-publiés et non revus par les pairs, donc à lire avec prudence, mais l'effet est assez réel pour un paragraphe honnête dans le cahier des charges.

Pour un pur travail de texte B2B, donc brouillons, extraction, classification et retrieval sur vos propres documents, cet effet est le plus souvent maîtrisable. C'est une question de qualité de sortie et d'image externe, pas une faille de sécurité. L'arc de souveraineté plus large, les modèles européens et ce que vaut vraiment le label, nous le traçons dans l'article sur l'IA européenne souveraine.

Comment je décide pour une PME

La décision n'est pas patriotique ni dictée par le classement, elle suit un ordre. Voici comment je procède :

1. Vérifier la licence. Seuls les modèles à vraie concession Apache ou MIT entrent en présélection sans question juridique. Ce sont ici Qwen3, Kimi K2 et Minimax M2.
2. Tester sur votre propre allemand. Pas le benchmark anglais, mais faire tourner cinquante de vos textes réels contre deux candidats et évaluer en aveugle.
3. Confronter au matériel. Ce qui tient sur vos une à deux cartes l'emporte presque toujours, car l'exploitation devient sinon coûteuse et fragile.

Pour la plupart des PME, cela aboutit à Qwen3 comme point de départ : libre de licence, largement multilingue, dans la bonne fenêtre matérielle. Kimi et Minimax sont le choix quand le serveur est de toute façon en place et que le reasoning ou les agents sont au premier plan. Le modèle de code open-weight Kimi K2.7, nous l'avons examiné spécialement à cet effet.

Et, comme toujours chez nous : construisez l'architecture de sorte à pouvoir changer de modèle. Le prochain meilleur modèle open-weight arrivera à coup sûr. La vraie question n'est pas lequel est en tête aujourd'hui, mais lesquelles de vos tâches ont réellement besoin du modèle le plus puissant et lesquelles seulement d'un bon, qui vous appartient. Lesquels de vos textes confieriez-vous à un modèle que vous n'avez pas testé vous-même ?

Cet article est la version praticien de cette configuration, et la version honnête de ses limites.

Le coffre est l'actif, l'agent est loué

Gardez séparés la chose durable et la chose remplaçable, et l'essentiel du design en découle.

La chose durable est votre coffre : de simples fichiers .md, des [[wikilinks]], un frontmatter YAML. Pas de base de données, pas de format propriétaire, pas d'étape d'export. La chose remplaçable est l'agent qui le lit. Les deux projets communautaires qui mènent cet espace, obsidian-second-brain et obsidian-mind, sont tous deux livrés à dessein pour Claude Code, Codex CLI et Gemini CLI. Le coffre est l'investissement ; le modèle est un locataire que vous pouvez expulser.

C'est le même raisonnement que nous appliquons au câblage de l'IA dans n'importe quel stack : posséder l'interface, louer la capacité. Nous l'avons rédigé pour l'intégration système dans API, MCP ou CLI. La gestion des connaissances personnelles est le même argument à l'échelle du bureau.

Ce qui change quand un agent peut lire vos notes

Un agent avec accès aux fichiers transforme un coffre statique en un coffre qui s'entretient lui-même, dans les limites que vous fixez.

• CLAUDE.md est le manuel d'exploitation. Lancez claude depuis la racine du coffre et il charge ce fichier à chaque session : votre carte de dossiers, vos conventions de liens, vos modèles de notes, vos comportements par défaut. C'est le seul fichier porteur de toute configuration qui fonctionne. /init en écrit un premier brouillon.
• Le contexte de session est un hook, pas de la magie. obsidian-mind injecte un extrait d'étoile polaire, une liste de tâches et un listing de fichiers au démarrage de session pour que l'agent ne commence pas à vide. C'est un hook SessionStart qui tourne sur votre machine, rien de plus.
• Le classement devient un skill. Commandes slash et sous-agents s'occupent des corvées : classer une note découpée dans le bon dossier, générer une carte de contenu, trouver les notes orphelines, écrire le journal quotidien. obsidian-second-brain en livre des dizaines.
• Le frontmatter est la couche lisible par machine. Date, statut, source, un marqueur de confiance en YAML, plus les wikilinks, donnent à l'agent une structure pour récupérer et croiser, au lieu de deviner à partir de la prose.

Le changement le plus récent, ce sont les notes qui se réécrivent plutôt que de s'empiler : une nouvelle source met à jour et réconcilie les notes existantes au lieu d'empiler une entrée datée de plus. Utile, et le premier endroit où être prudent, ce qui est la section d'après la prochaine.

Récupérer, pas déverser : la réalité des tokens

Ne chargez pas tout le coffre. Laissez l'agent aller chercher les quelques notes dont une question a besoin.

La configuration naïve pousse le coffre dans le contexte et casse autour de quelques centaines de notes. La configuration frugale garde tout sur le disque et ne tire que ce qui correspond, via une recherche en ligne de commande ou grep. Des praticiens rapportent l'écart comme environ 100 tokens pour une recherche de coffre en CLI contre des dizaines de milliers pour charger un projet en bloc. La mécanique est sans gloire : chercher, lire les trois notes correspondantes, répondre.

Cela compte encore même si Claude Code dispose désormais d'une fenêtre de contexte d'un million de tokens. La limite de débit glissante mord bien avant que la fenêtre ne se remplisse, si bien qu'un coffre qui répond en 100 tokens vous laisse poser cent questions là où la configuration tout-charger vous en donne une poignée. La récupération frugale est ce qui rend un second cerveau utilisable au quotidien plutôt qu'impressionnant une fois.

La ligne de confidentialité est l'inférence, pas le stockage

La communauté vend « tout reste dans votre coffre, pas de SaaS ». C'est vrai pour le stockage et faux pour l'inférence, et la différence est tout le risque.

Votre Markdown reste sur votre disque. Mais par défaut, chaque requête envoie les notes pertinentes à une API cloud pour être lues. Pour un coffre de recettes de loisir, très bien. Pour un coffre contenant des notes clients, des contrats ou quoi que ce soit couvert par un contrat de sous-traitance, ce sont des données qui quittent le bâtiment à chaque question. La portabilité du Markdown simple n'est pas la même chose que la confidentialité locale.

Deux réserves honnêtes de plus. L'injection de prompt est structurelle : un agent qui lit vos notes ne peut pas séparer proprement « instructions » et « contenu », si bien que tout Markdown qui entre dans le coffre, une page web découpée, une note partagée, un PDF ingéré, peut porter des instructions sur lesquelles il agit ensuite. Et le risque n'est pas hypothétique : en avril 2026, des attaquants ont abusé de plugins communautaires Obsidian pour exécuter du code à l'ouverture d'un coffre partagé par une victime, rapporté par The Hacker News. Un agent avec accès en écriture et au shell relève cet enjeu, il ne l'abaisse pas. Les notes qui se réécrivent peuvent aussi inventer discrètement un rétrolien ou écraser une ligne correcte, et le changement est enregistré avant que vous ne le lisiez.

Le même schéma, gardé souverain

Tout ce qui est bon dans cette configuration survit quand vous rapatriez le modèle en interne. Le problème de confidentialité est la seule partie qui a besoin du changement.

La version souveraine garde le coffre et le flux de travail et échange l'inférence cloud contre un modèle local : une couche de récupération au-dessus de votre Markdown servie par un modèle qui tourne sur votre propre matériel ou en hébergement UE. Vous gardez la propriété du texte brut, le manuel d'exploitation CLAUDE.md, les skills, et vous cessez d'envoyer le contenu au-dehors à chaque question. Pour une PME, c'est le pont entre une expérience personnelle et une vraie gestion des connaissances internes, manuels produit, docs de processus, historique de support, sans qu'une question de sous-traitance pèse sur chaque requête. Quand faire ce pas, et ce qu'il coûte, fait l'objet d'On-Premise contre LLM cloud.

Le cadrage amateur est « construire un second cerveau ». Le cadrage professionnel est la même machine pointée sur le savoir de l'entreprise plutôt que le vôtre. La question intéressante, encore une fois, n'est pas de savoir si cela fonctionne. C'est de savoir qui a le droit de lire les notes. Alors : où votre coffre envoie-t-il réellement ses questions en ce moment ?

Cet article situe les deux : ce qui est déjà fort, où cela coince, et ce qui en découle pour une entreprise locale.

La recherche est là, et elle est dense

Le versant recherche n'a à rougir devant aucun Land. Il est seulement fortement concentré.

Kaiserslautern porte le cœur : site principal du DFKI, la RPTU avec huit chaires d'IA, Fraunhofer IESE et ITWM, plus une coopération avec l'Institut Max Planck. Le tout premier Centre d'innovation et de qualité en IA de Mission KI au niveau fédéral y siège également, avec 32 M d'euros de budget fédéral. Coblence bâtit le second pôle : l'université a lancé en juillet 2025 un hub IA interdisciplinaire, la Hochschule Koblenz exploite avec DigiMit un centre de compétences pour la région.

L'appréciation honnête figure juste à côté. Le cluster est pondéré vers KL et Coblence, le terrain est plus faiblement raccordé, et dans la comparaison fédérale la RLP est dans le peloton de tête, pas au sommet. En numérisation, la Bavière, Berlin et Hambourg mènent, en innovation le Bade-Wurtemberg.

Le Land mise lui-même sur une IA souveraine

Remarquable est ce avec quoi le Land travaille : non pas un abonnement cloud américain, mais une ligne propre et souveraine.

L'agenda IA du Land nomme un triptyque IA, et l'un des trois piliers s'appelle expressément LLM On-Premise. Avec GPU4GenAI, le Land investit dans sa propre infrastructure GPU au DFKI, et depuis septembre 2025 une coopération sur trois ans avec le DFKI amène l'IA dans l'administration du Land : analyse documentaire, plateformes de données sûres, systèmes d'assistance.

C'est plus qu'une note en marge. Quand la puissance publique en RLP construit une IA conforme à la protection des données et exploitée localement, alors le conseil en on-premise et en souveraineté pour les PME n'est pas un sujet de niche, mais un prolongement de ce que le Land montre l'exemple. Le graphique ci-dessous montre le problème de fond : des nœuds forts, trop peu de lignes vers le terrain.

Dans les PME, la situation est différente

À l'établi, la vitesse est autre, et les chiffres sont lucides.

Dans une enquête de la Hochschule Koblenz dans le nord de la RLP (176 entreprises, décembre 2025), seulement 8,5 pour cent jugent l'IA aujourd'hui centrale pour le modèle d'affaires, dans cinq ans tout de même 42 pour cent. Plus d'un quart utilise déjà des outils d'IA, environ la moitié teste dans des projets pilotes. Une seconde étude régionale de l'IHK et de la chambre des métiers de Coblence montre le vrai motif : près de deux tiers utilisent l'IA, dont la plupart depuis deux ans au plus, presque 90 pour cent misent sur des logiciels externes, et le plus grand défi cité est la sécurité juridique.

Recherche de pointe et diffusion vers la masse sont donc deux choses différentes. L'une est ici présente, l'autre pas encore.

L'écart est la mise en œuvre, pas la technique

L'obstacle dans les PME est rarement le modèle. C'est le chemin de l'idée à un usage sûr et productif.

Au niveau fédéral, seul environ un tiers des entreprises a une stratégie d'IA élaborée, en RLP le manque d'expertise est cité à répétition comme frein. Et les presque 90 pour cent qui misent sur des logiciels externes achètent avec cela de la dépendance, souvent à des services cloud américains, précisément là où ces mêmes entreprises indiquent la sécurité juridique comme première préoccupation. C'est une contradiction annoncée.

Une relativisation honnête s'impose : les taux d'usage surestiment la maturité. Beaucoup relève d'un usage informel d'outils librement accessibles, sans stratégie, sans gouvernance, sans cadre clair de protection des données. Dans les PME, la question n'est plus depuis longtemps l'IA oui ou non. Elle est souverain et productif plutôt qu'informel et risqué. Ce que cela signifie en pratique, nous l'avons décliné dans la feuille de route pratique de l'IA pour les PME.

Ce que cela signifie pour les entreprises en RLP

La stratégie évidente est celle que le Land suit déjà : encaisser l'utilité sans céder la souveraineté des données.

La brique manquante n'est pas un outil de plus, mais la couche entre subventions et recherche d'un côté et usage productif et souverain de l'autre. Concrètement : des modèles locaux ou hébergés en Allemagne pour les données sensibles, une gestion des connaissances par RAG sur son propre fonds documentaire, et un chemin lucide de la sélection du cas d'usage jusqu'au pilote. Quand l'IA locale vaut la peine par rapport au cloud, nous le situons dans On-Premise contre LLM cloud.

Chez iiterate, nous sommes à Coblence et à Remagen, donc au cœur du second pôle IA du Land, et c'est précisément cette couche de diffusion qui est notre travail : réunir stratégie, construction et conformité, plutôt que de laisser les PME seules entre la notification d'aide et l'établi. La recherche en RLP est acquise. La question plus captivante est de savoir à quelle vitesse elle atteint le terrain, et qui trace les lignes pour cela.

Ce texte explique pourquoi le contexte long est coûteux, quelles approches subquadratiques existent, ce qui est étayé parmi les promesses les plus tapageuses, et ce que cela apporte concrètement au RAG on-prem. La recommandation finale est peu spectaculaire et c'est précisément pourquoi elle est solide.

Pourquoi le contexte long est coûteux

La raison tient aux mathématiques de l'auto-attention : son effort croît quadratiquement avec la longueur de l'entrée.

Dans un transformeur classique, chaque token compare chaque autre. Si la longueur de contexte double, l'effort de calcul de l'attention quadruple grosso modo. S'y ajoute la mémoire : le cache clé-valeur que le modèle traîne pendant la génération croît linéairement avec la longueur et dévore vite la mémoire disponible sur un GPU fixe. C'est le véritable goulet d'étranglement en exploitation on-prem, où le matériel est acté et non loué de façon élastique.

C'est précisément là qu'agissent les approches subquadratiques. Elles tentent de pousser le coût de séquence vers le linéaire, donc O(n) au lieu de O(n au carré), et de limiter la mémoire par token. Ce que cela signifie pour la réalité matérielle en entreprise, nous l'avons calculé dans LLM local.

Le paysage subquadratique

Il y a plusieurs voies, et le vainqueur pratique des années 2024 à 2026 n'est pas la plus pure, mais l'hybride.

• Modèles à espace d'états (Mamba). Mamba (décembre 2023) et Mamba-2 (mai 2024) modélisent les séquences en temps linéaire avec une mémoire d'état fixe plutôt qu'un cache croissant (arXiv). Le prix : un état fixe est un compresseur avec perte et plus faible pour se souvenir exactement d'endroits très en arrière.
• Attention linéaire (RWKV, RetNet). Reformulent l'attention pour que le coût croisse à peu près linéairement. Compromis similaire sur la mémoire associative.
• Hybrides en production. Personne ne livre de modèles purement subquadratiques de qualité de pointe. Au lieu de cela, tous mélangent une minorité de couches à attention pleine avec une majorité de couches à espace d'états ou linéaires : Jamba (AI21, 2024), MiniMax-01 (janvier 2025), Falcon-H1 (mai 2025), Nemotron-H de NVIDIA, IBM Granite 4.0 (octobre 2025) et Qwen3-Next (septembre 2025). Les couches pleines préservent la mémoire, les couches légères achètent l'avantage en coût et en mémoire.

La lignée NVIDIA derrière Nemotron, qui utilise précisément cette architecture hybride, nous l'avons décrite dans Nemotron 3.

Ce que « subQ » promet, et ce qui en est étayé

Le terme exige de la prudence, car il porte deux sens, un architectural et un marketé.

Outre la famille subquadratique générale, il existe un produit concret : la start-up Subquadratic est sortie de l'ombre en mai 2026 avec un financement d'environ 29 millions de dollars et se prévaut d'une attention subquadratique et parcimonieuse. Les titres sont énormes : un modèle de recherche à 12 millions de tokens de contexte, environ un cinquième du coût par rapport aux modèles de pointe, une vitesse démultipliée (The New Stack).

L'appréciation honnête : une partie est vérifiée par des tiers, par exemple un résultat RULER-128K, tandis que les chiffres spectaculaires sur 12 millions de tokens et le facteur de vitesse sont des données du fournisseur issues de passages isolés et non reproduites de façon indépendante. C'est un indice prometteur, pas une base d'achat. C'est précisément cette distinction, étayé contre affirmé, qui est la discipline que nous appliquons à chaque nouveau modèle.

Ce que cela apporte au RAG on-prem

Le gain concret est de la mémoire et du débit sur du matériel fixe, et c'est pour le RAG on-prem exactement le bon réglage.

• Cache limité, mémoire prévisible. Les couches à espace d'états portent un état fixe, la mémoire n'explose donc pas avec la longueur. IBM annonce pour Granite 4.0 plus de 70 pour cent de besoin en moins sur contexte long, une donnée du fournisseur, mais plausible et allant dans le sens de plus de sessions simultanées par GPU.
• Modèle et contexte sur une seule carte. NVIDIA rapporte qu'un modèle Nemotron-H de 51 milliards de paramètres tient avec son cache sur une seule carte de 80 Go, également une donnée du fournisseur.
• Discipline de chunking plus souple. Un contexte moins cher permet des fenêtres plus grandes et un découpage moins craintif des documents.

Des réserves honnêtes s'imposent. Pour le RAG à forte charge mémorielle, par exemple la fundstelle exacte sur des textes très longs, les modèles purement subquadratiques restent en deçà de l'attention pleine, les hybrides comblent largement l'écart, mais pas entièrement. L'écosystème d'outillage, donc quantisation, serving et fine-tuning, est en retard sur les modèles denses établis. Et la phrase la plus importante : contexte long n'est pas égal à bon retrieval. Un modèle solide avec un bon RAG bat aujourd'hui presque toujours la tentative de simplement y déverser des millions de tokens. Ce que le RAG apporte tout court, c'est dans Qu'est-ce que le RAG et La force du RAG.

Comment je traite cela aujourd'hui

Subquadratique vaut la peine d'être observé, mais pas le pari. Voici comment je m'y prends :

1. Construire la couche RAG indépendamment du modèle. Derrière une interface stable, de sorte qu'un hybride de classe Granite 4 puisse être déployé dès que l'outillage est mûr.
2. Démarrer avec un modèle solide et bien pris en charge, pas avec l'architecture la plus récente, et tirer la valeur de la qualité du retrieval.
3. Ignorer les promesses non étayées. Un facteur revendiqué de mille attend que quelqu'un d'indépendant le reproduise.

C'est le même schéma que nous tirons pour On-Premise contre cloud : décider à dessein, construire remplaçable (On-Premise contre LLM cloud). La question captivante n'est pas de savoir si les modèles subquadratiques rendront un jour le contexte long bon marché. Ils le feront probablement. La question est de savoir si votre architecture est prête à en tirer le gain, sans que vous pariiez dessus aujourd'hui. Votre couche RAG est-elle construite de sorte à pouvoir changer de modèle sans tout réécrire ?