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

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.

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.

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.

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

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.

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.

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 ?

La plupart des équipes qui intègrent l'IA dans leurs systèmes n'ont pas besoin de désigner un vainqueur. Elles doivent placer chaque appel à la bonne hauteur. Cet article définit les trois notions clairement, montre quand chacune convient, nomme les coûts que l'on oublie, et se conclut par une décision que vous pouvez défendre. Deux questions règlent l'essentiel : combien d'intégrations faites-vous tourner, et qui doit les auditer ?

Trois couches, pas trois rivales

Chaque modèle se situe à un niveau d'abstraction différent, avec un arbitrage net entre contrôle et commodité.

• Un appel API direct est la brique la plus basse. Votre code appelle un modèle ou un service via HTTP. Vous obtenez un contrôle maximal et un outillage standard, et vous écrivez la glu : authentification, requête, analyse de la réponse, gestion des erreurs.
• MCP, le Model Context Protocol, standardise la connexion, pas le modèle. C'est un standard ouvert introduit par Anthropic en novembre 2024 qui offre au modèle une manière cohérente de découvrir et d'appeler des outils et des données, de sorte qu'un client compatible MCP puisse dialoguer avec un serveur MCP qu'il n'a jamais rencontré (Wikipedia). Il s'est répandu vite : en 2025, il a été adopté par OpenAI, Google et Microsoft, a dépassé les 5 800 serveurs communautaires en avril 2025, et fin 2025 faisait état de dizaines de millions de téléchargements mensuels de SDK avant qu'Anthropic ne le confie à une initiative de la Linux Foundation (Thoughtworks, The New Stack).
• Une CLI agentique est la couche la plus haute. Un outil comme Claude Code regroupe un modèle, un ensemble d'outils et une boucle de raisonnement dans un flux de travail en terminal. Le moins de glu, le plus d'opinions arrêtées, le plus rapide pour le travail ouvert.

Elles se composent plutôt qu'elles ne s'affrontent : une CLI agentique peut appeler des serveurs MCP, qui à leur tour enveloppent de simples API (iiterate).

Quand chacune est à la bonne hauteur

Le choix découle de la forme du travail, pas de la nouveauté de l'option. Une brève cartographie :

En pratique : un traitement batch nocturne qui interroge un seul endpoint devrait appeler l'API directement, car MCP ajouterait de la latence et des points de défaillance sans aucun bénéfice. MCP prouve sa valeur dès que plusieurs agents ont besoin des mêmes intégrations, si bien que chaque client MCP obtient une interface cohérente unique plutôt que chaque agent portant son propre wrapper. Le point de bascule rapporté par les praticiens se situe autour de trois intégrations connectées à l'IA ou plus (MindStudio). Une CLI agentique convient lorsque la tâche est ouverte et que quelqu'un a besoin de résultats rapides à travers de nombreux outils.

Les coûts que l'on oublie

Les bénéfices affichés sont faciles à trouver. Ce sont les coûts plus discrets qui décident si un choix vieillit bien.

• Les tokens. Une couche d'outils standardisée n'est pas gratuite. Lorsqu'un agent appelle un même outil de façon répétée, le coût de découverte de MCP peut consommer bien plus de tokens qu'un appel CLI ou API direct pour la même tâche (MindStudio).
• L'observabilité. Les appels HTTP apparaissent dans vos journaux, et des outils standard comme Datadog les tracent sans effort. Le transport MCP est comparativement opaque, et sa supervision en production est encore en maturation, si bien que vous payez en instrumentation sur mesure (IJONIS).
• Le verrouillage et la portabilité. Une API brute maintient l'intégration dans du code que vous possédez. Plus vous montez, plus vous dépendez d'un client, d'un écosystème de serveurs ou de l'agent d'un fournisseur. Gardez une voie de retour vers la couche inférieure.

La surface de sécurité de MCP est nouvelle et bien réelle

Standardiser la façon dont les modèles atteignent les outils standardise aussi une nouvelle surface d'attaque, et elle mérite un traitement explicite.

L'OWASP classe l'injection de prompt comme la première vulnérabilité des applications LLM en 2025. MCP y ajoute une variante spécifique, l'empoisonnement d'outil, où des instructions malveillantes sont dissimulées dans la description d'un outil, plus proche d'une attaque de la chaîne d'approvisionnement sur le contexte de l'agent que d'un jailbreak côté utilisateur, et suivie sous la référence CVE-2025-54136 (TrueFoundry). Parce que les serveurs MCP détiennent souvent des identifiants et atteignent des systèmes réels, un serveur surprivilégié ou non fiable constitue un risque sérieux, et les protections côté client varient fortement (Simon Willison, Microsoft). La posture pratique : n'exécuter que des serveurs validés, accorder à chacun le moindre privilège et maintenir une supervision, les mêmes questions de gouvernance qui s'appliquent dès qu'un agent touche à des données réelles (iiterate).

Une décision que vous pouvez défendre

Vous n'avez pas besoin d'une réponse unique pour toute l'entreprise. Vous avez besoin de la bonne hauteur par intégration. Une règle qui fonctionne :

1. Optez par défaut pour une API directe dès qu'il s'agit d'un appel unique, stable et à fort volume.
2. Tournez-vous vers MCP quand plusieurs agents ont besoin des mêmes outils, ou que vous voulez des outils interchangeables derrière une seule interface.
3. Utilisez une CLI agentique quand le travail est ouvert et qu'une personne ou un autre agent le pilote.
4. Quelle que soit la couche, conservez le moindre privilège, de vrais journaux et un moyen de redescendre d'une couche si un fournisseur change ses conditions.

Pour la plupart des systèmes en production, la réponse honnête est un mélange : des API directes sous les services, MCP comme couche de traduction et de découverte pour les agents, et une CLI là où les humains travaillent. Le vrai piège n'est pas de choisir le mauvais outil. C'est d'adopter la couche la plus récente parce qu'elle est la plus récente, et d'en payer les coûts pour un travail qu'une couche inférieure aurait mieux fait.

Le propos de l'article n'est pas les événements. C'est la forme. event-scout est une micro-app agentique : quelque chose que l'on construit une fois avec un agent de code puis que l'on laisse tourner, où l'agent fait le jugement délicat et de simples scripts font la plomberie ennuyeuse et reproductible. Cette répartition est toute la leçon, et elle vaut pour presque chaque tâche interne qu'une équipe de PME continue de faire à la main. event-scout tourne sur la plus haute de ces couches, une CLI agentique (iiterate).

CE QU'IL FAIT, CONCRÈTEMENT

À chaque exécution, event-scout parcourt une base de sources sélectionnées : sites d'événements, calendriers, newsletters et quelques flux LinkedIn. De tout ce qu'il récupère, il ne garde que les événements en présentiel, futurs et à portée de Remagen, note chacun selon son utilité pour nous, retire les doublons dans un magasin unique et reconstruit un tableau de bord que nous ouvrons vraiment.

Prise isolément, aucune de ces étapes n'est vraiment nouvelle. Ce qui fait que cela fonctionne, c'est que le tout tourne sans surveillance selon un calendrier, et que le jugement appliqué est le nôtre, pas un filtre de pertinence générique. La sortie n'est pas un flux de tous les événements tech d'Allemagne. C'est une réponse courte et classée à une seule question : où devrions-nous nous montrer ensuite.

LA FORME QUI L'A FAIT FONCTIONNER : L'AGENT POUR LE JUGEMENT, LES SCRIPTS POUR LA PLOMBERIE

La décision de conception qui compte, c'est où le modèle s'arrête et où un script commence.

La récupération est déléguée à un assistant déterministe. Un petit orchestrateur Node rend chaque source à échéance dans un vrai navigateur headless, gérant ainsi les pages JavaScript, les protections anti-bot légères et les listes à chargement paresseux, et il capture les données d'événement structurées schema.org quand une page les expose. C'est de la plomberie : fiable, planifiable, identique à chaque fois.

L'agent lit ce que le récupérateur a enregistré et fait les parties qui résistent au codage en dur : extraire de vrais événements de pages en désordre, décider ce qui compte comme présentiel et pertinent, noter chacun, et repérer que deux annonces désignent le même événement. Un second petit moteur fusionne ensuite, élague les anciennes entrées et régénère le tableau de bord.

🔸 Ne faites pas faire au modèle ce qu'un script fait à bas coût.
Rendre une page et écrire un fichier est un travail déterministe. Le confier au modèle serait plus lent, plus coûteux et moins fiable.

🔸 Ne faites pas faire à un script ce qui demande du jugement.
Savoir si une annonce à moitié formatée est un événement réel, pertinent et présentiel est exactement le jugement où un modèle excelle et où une regex échoue.

Placer cette ligne au bon endroit est l'essentiel de ce qui fait de l'outil un dispositif fiable plutôt qu'une démo astucieuse.

IL S'AUTORÉGLE

Un scout qui vérifie chaque source à parts égales à chaque exécution gaspille l'essentiel de son effort, car les événements n'apparaissent pas de façon uniforme.

Chaque source porte donc son propre bref historique de rendement. Les sources qui produisent régulièrement des événements pertinents sont vérifiées à chaque exécution. Celles qui reviennent vides sont mises en pause selon un délai croissant, une semaine, puis deux, puis un mois, et sont retestées à son expiration plutôt que supprimées. Une source qui n'a simplement rendu aucun événement est discrètement déprioritisée ; seule une source qui échoue plusieurs fois de suite au chargement est retirée comme défectueuse.

L'effet est que l'attention se porte là où les événements apparaissent réellement, et cela s'ajuste tout seul sur des semaines sans que personne ne s'en occupe. Cet autoréglage est ce qui fait du sans-surveillance une promesse réelle et non un espoir.

UN SCORING ASSUMÉ VAUT MIEUX QU'UN FLUX GÉNÉRIQUE

Le score est délibérément le nôtre. Chaque événement obtient une valeur sur 100, pondérée pour notre situation : sa proximité et sa facilité d'accès, la densité de la salle en acheteurs du type que nous servons, son caractère intime, l'existence d'un levier concret comme une remise ou une prise de parole, et son échéance.

La pondération porte une opinion que nous avons sur la vente. Une grande conférence ne se classe haut que s'il existe un vrai levier à utiliser, car pour une vente relationnelle une salle bondée sans porte d'entrée vaut moins qu'une petite table ronde régionale où l'on peut vraiment parler aux gens. Le résultat se lit comme un cockpit de décision plutôt qu'un calendrier : il pointe où passer une journée, pas tout ce qui existe.

Un flux d'événements générique ne pourrait pas encoder cela, car le jugement est propre à la façon dont une équipe donnée gagne des affaires. Cette spécificité est la raison pour laquelle il valait la peine de le construire plutôt que de l'acheter.

POURQUOI UNE MICRO-APP, ET NON UN SAAS

event-scout est petit à dessein. L'ensemble tient en une poignée de fichiers JSON pour les sources et le magasin d'événements, deux ou trois scripts, et un tableau de bord HTML autonome qui s'ouvre directement depuis le disque. Il n'y a pas de base de données à faire tourner ni d'abonnement à renouveler. Les données restent nôtres, et le scoring aussi.

C'est le même mouvement que les propres équipes non techniques d'Anthropic ont décrit, construire de petits outils internes avec un agent de code plutôt que de déposer une demande et attendre (claude.com). Nous avons aussi écrit sur ce schéma du côté utilisateur (iiterate).

Il n'est pas exempt d'aspérités, et prétendre le contraire serait malhonnête. Les sources derrière un mur de connexion nécessitent qu'une session soit capturée à la main une fois. Quelques sites récalcitrants restent des pistes manuelles plutôt que de faux résultats. Et nous vérifions chaque reconstruction en contrôlant directement la structure de la page, car une capture d'écran cale sur le chargement d'une police. Rien de tout cela ne change la conclusion : quand une tâche est répétable et propre à votre façon de travailler, un agent de code peut la transformer en un petit outil possédé pour moins cher que le SaaS ou les heures manuelles qu'il remplace. La question plus difficile n'est pas de savoir si vous pouvez en construire un. C'est laquelle de vos corvées hebdomadaires attendait discrètement de le devenir.

Claude Code est conçu pour les ingénieurs, mais le travail qu'il a discrètement pris en charge pour nous se situe dans le marketing et l'administratif : les tâches répétitives et réglées par des règles que personne n'aime. La raison pour laquelle il y trouve sa place est simple. Quelqu'un qui connaît une procédure, les règles de marque, la liste de contrôle de fin de mois, la manière dont nous étiquetons l'export d'une campagne, l'écrit une fois en langage clair, et l'agent l'exécute sur de vrais fichiers. Aucun projet logiciel, aucun développeur dans la boucle. Cet article rassemble ce que nous avons appris sur les cas où cela paie, ceux où cela ne paie pas, et comment démarrer sans regret.

Le vrai changement n'est pas de coder. C'est d'écrire la procédure

Pour un non-développeur, un agent de code est un moyen de transformer une procédure répétitive en quelque chose qu'une machine exécute, sans construire de logiciel au préalable.

Le mécanisme qui rend cela possible hors de l'ingénierie, ce sont les Agent Skills. Un skill est un petit dossier : un fichier d'instructions en langage clair, éventuellement un script ou deux, et le matériel de référence dont il a besoin. L'agent ne voit que le nom d'un skill et une description d'une ligne jusqu'à ce que votre tâche en ait besoin, puis il lit les instructions complètes à la demande. Simon Willison, qui a documenté le format lors de sa sortie en octobre 2025, en a résumé l'économie sans détour : chaque skill ne coûte que quelques dizaines de tokens jusqu'au moment où il est utilisé (simonwillison.net, Anthropic).

La conséquence est la partie qui compte pour une équipe du Mittelstand :

🔸 L'auteur est un expert métier, pas un codeur.
La personne qui connaît le processus écrit le skill, comme elle briefierait une nouvelle recrue.

🔸 Les connecteurs lui donnent une vraie portée.
Via MCP, un standard ouvert de connecteurs, l'agent peut lire et agir dans de vrais systèmes, un tableur, un lecteur partagé, une file de tickets, dans les limites d'accès que vous accordez.

🔸 C'est vous qui décidez du rayon d'action.
Il ne touche que ce que vous l'autorisez à toucher. Cette frontière de permission est tout l'enjeu, et nous y revenons plus bas.

Trois tâches ennuyeuses où cela paie vraiment

Les gains sont peu glamour et répétitifs. Trois schémas ont tenu bon pour nous et dans les témoignages publics.

Des variantes marketing à grande échelle. L'équipe Growth Marketing d'Anthropic a elle-même relié deux sous-agents spécialisés pour lire un CSV de centaines de publicités actives, repérer les moins performantes et rédiger de nouvelles variantes dans des limites strictes de caractères, quelques minutes de travail au lieu d'heures. Un plugin Figma associé génère jusqu'à 100 variations de mise en page par lot en permutant titres et descriptions (claude.com). C'est leur propre équipe, à lire donc comme la preuve que le schéma fonctionne, pas comme votre chiffre.

Le nettoyage de données administratif. Le milieu terne de la semaine : réconcilier un relevé de carte dans une note de frais, nettoyer une liste en désordre, rédiger un rapport récurrent à partir d'un modèle. Un fondateur solo et non technique sur r/SaaS a raconté avoir mené pour ainsi dire toute son activité SEO via Claude, rapportant 1,54 million d'impressions de recherche et 12 900 clics en trois mois sans ingénieur ni agence (r/SaaS). Le témoignage d'une seule personne, mais un témoignage éloquent.

Des outils internes construits par la personne qui en a besoin. L'équipe juridique d'Anthropic a prototypé un petit « arbre téléphonique » qui oriente une question vers le bon juriste, construit par un juriste produit qui n'écrit pas de code (claude.com). Ce qui est intéressant, ce n'est pas l'outil. C'est qui l'a construit, et le fait qu'il n'ait pas eu à ouvrir un ticket pour cela.

Nous avons déjà écrit sur les endroits où l'IA gagne réellement sa place dans une entreprise plutôt que là où elle fait bonne figure en démonstration (iiterate) ; c'est le même test appliqué à un seul outil.

Pourquoi le marketing et l'exploitation, précisément

Ces fonctions conviennent parce que leur travail est répétitif, réglé par des règles, et vit déjà dans des fichiers.

Cela correspond parfaitement à ce qu'un skill peut contenir. Un skill de charte graphique porte la palette, les règles typographiques et le ton de voix. Un skill de procédure porte la liste de contrôle de clôture ou une étape de conformité. Un skill de modèle porte le document lui-même. Anthropic livre un skill de charte graphique opérationnel en exemple public, avec des règles de couleur, de typographie et de mise en page qu'un agent applique à la demande (GitHub, Anthropic).

Le constat récurrent dans ces témoignages est que l'expertise métier détermine le résultat davantage que la compétence en code. C'est là l'atout discret du Mittelstand. La personne qui connaît le processus est déjà dans les murs, et un skill n'est que son processus, mis par écrit.

Là où c'est le mauvais outil

Un agent de code est le mauvais outil dès l'instant où le travail cesse d'être répétitif, vérifiable ou sûr à confier à un agent doté d'un large accès. Les risques honnêtes, dans l'ordre où ils mordent :

Le rayon d'action. Un agent ayant accès aux fichiers et au système peut supprimer le mauvais dossier ou envoyer le mauvais message. Accordez-lui le moindre privilège : lecture seule d'abord, un seul dossier, une copie des données, pas l'original. Les équipes de sécurité ont recensé ce qui tourne mal quand on saute cette étape (Docker, Oso).

Des réponses fausses mais assurées. Il énoncera un chiffre qu'il n'a pas vérifié, dans une prose fluide. Gardez un contrôle humain sur tout ce qui sort de l'entreprise.

La gouvernance et les données. Dès qu'il touche à des données personnelles ou clients, le RGPD et l'EU AI Act s'appliquent. Sachez où résident les données et qui peut être audité avant de les connecter, c'est la même question de contrôle qui sous-tend le fait de faire tourner des modèles que l'on possède plutôt que l'on loue (iiterate).

La provenance. La plupart des études de cas soignées, y compris deux dans cet article, sont publiées par des fournisseurs. Lisez-les comme la preuve que le travail est possible, pas comme la preuve de votre rendement.

Comment démarrer sans regret

Commencez petit, sur un travail que vous pouvez vous permettre de rater.

1. Choisissez une tâche répétitive et réglée par des règles, qui n'est pas votre processus le plus important.
2. Écrivez la procédure sous forme de skill en langage clair, comme vous briefieriez une recrue compétente à son premier jour.
3. Accordez un accès au moindre privilège : lecture seule, un seul dossier, une copie des données.
4. Gardez un contrôle humain sur tout ce qui sort ou touche aux données d'une personne.
5. Mesurez sur la métrique ennuyeuse, les heures gagnées sur la tâche pénible, pas sur l'impression laissée par la démonstration.

Menés ainsi, les gains sont petits et ils se cumulent, ce qui est l'inverse de la manière dont cette technologie est habituellement vendue. La question qui vaut la peine d'être posée n'est pas de savoir si un agent de code peut faire du marketing ou de l'exploitation. C'est de savoir lesquelles de vos procédures vous avez réellement mises par écrit, car c'est cela, et non le modèle, qui décide jusqu'où cela peut aller.

L'avis clé du Comité européen de la protection des données sur les modèles d'IA s'appuie sur la formule « au cas par cas », et les lignes directrices conjointes du CEPD et de la Commission européenne sur la rencontre entre le RGPD et le règlement européen sur l'IA ne sont pas attendues avant début 2026. La question utile n'est donc pas « l'IA est-elle autorisée sous le RGPD ». C'est « sous quelles conditions, et lesquelles de ces conditions contrôlons-nous réellement ». Cet article cartographie les quelques limites strictes, le vaste milieu conditionnel, et les leviers qu'une équipe de PME peut actionner. C'est une orientation, pas un conseil juridique, alors associez votre délégué à la protection des données avant d'agir.

COMMENCEZ PAR LES QUELQUES CHOSES RÉELLEMENT RESTREINTES

Une courte liste d'usages de l'IA est proche d'une véritable interdiction sous le RGPD. Les connaître d'abord rend le reste plus facile à raisonner.

• Décisions uniquement automatisées sur les personnes. L'article 22 restreint les décisions à effet juridique ou similairement significatif prises sans intervention humaine véritable. Les autorités de contrôle allemandes le lisent strictement et attendent une supervision humaine effective plutôt qu'un tampon de complaisance (Hogan Lovells).
• Données de catégories particulières par défaut. Les données de santé, biométriques, de croyance et assimilées sont interdites de traitement sous l'article 9 sauf si une exception précise s'applique. Le règlement européen sur l'IA ajoute une ouverture étroite : l'article 10(5) autorise de telles données strictement pour détecter et corriger des biais dans les systèmes à haut risque (IAPP).
• Modèles construits sur des données collectées illicitement. L'avis 28/2024 du CEPD, publié le 18 décembre 2024, estime que si un modèle a été développé à partir de données personnelles traitées illicitement, cela peut vicier la licéité de son déploiement, sauf si le modèle a été dûment anonymisé (CEPD).

La plupart du travail sur l'IA se situe hors de cette courte liste, où la réponse est rarement un « non » franc. C'est un « oui, si ».

L'ESSENTIEL EST CONDITIONNEL, PAS INTERDIT

Le vaste milieu du travail sur l'IA est licite quand vous pouvez démontrer les bonnes conditions et les documenter.

Deux conditions font l'essentiel du travail. La première est une base légale. Pour l'entraînement et l'usage de modèles sur des données personnelles, le CEPD a posé un test en trois étapes pour s'appuyer sur l'intérêt légitime, pesant l'intérêt lui-même, la nécessité du traitement, et une mise en balance avec les droits des personnes concernées (CEPD). L'intérêt légitime est disponible, mais il se gagne par ce test, il ne se présume pas.

La seconde est l'anonymat, que vous ne pouvez pas déclarer vous-même. Le même avis estime qu'un modèle entraîné sur des données personnelles n'est pas automatiquement anonyme. Il ne compte comme anonyme que lorsqu'il est très improbable à la fois d'identifier les personnes dont les données l'ont entraîné et de faire extraire ces données par des requêtes, appréciation faite au cas par cas par l'autorité de contrôle (IAPP). L'avis s'appuie tant sur « au cas par cas » que des analystes juridiques ont compté les occurrences de la formule dans le texte (Ropes & Gray). La lecture pratique : la plupart des traitements d'IA sont permis, à la condition que vous puissiez démontrer votre base et votre documentation.

LES CONDITIONS SONT SURTOUT ARCHITECTURALES

Le point encourageant est que les conditions à remplir sont largement déterminées par la façon dont vous construisez le système, pas par qui vous êtes.

• Garder moins, moins longtemps. La minimisation des données et la limitation des finalités s'appliquent aux endroits propres à l'IA où les données se cachent : journaux de prompts et de système, et les vecteurs dans un magasin RAG. Les lignes directrices du CEPD pointent vers la minimisation de ce qui est journalisé, la préférence pour des identifiants agrégés ou pseudonymes, et une conservation courte (analyse du CEPD).
• Décider où résident les données, à dessein. Depuis l'arrêt Schrems II, envoyer des données personnelles à un fournisseur américain ne se règle pas en signant des clauses contractuelles types. Vous devez évaluer si ces clauses peuvent réellement être respectées compte tenu du droit de surveillance américain, et cette responsabilité ne peut être confiée au fournisseur (analyse).

C'est la raison pratique pour laquelle la résidence des données et le déploiement on-prem sont des leviers de contrôle plutôt qu'une idéologie, le même point que derrière le fait de faire tourner des modèles que vous possédez plutôt que loués (iiterate).

LE RGPD ET LE RÈGLEMENT EUROPÉEN SUR L'IA SONT DEUX RÉGIMES, PAS UN

Il aide de traiter la protection des données et la régulation de l'IA comme des obligations distinctes qui se rencontrent, plutôt qu'un règlement unique.

Le RGPD est un régime de droits fondamentaux portant sur les données personnelles ; le règlement européen sur l'IA est plus proche d'un droit de la sécurité des produits pour les systèmes d'IA (IAPP). Un même système à haut risque peut devoir des obligations au titre des deux : une analyse d'impact relative à la protection des données au titre de l'article 35 du RGPD, et une analyse d'impact sur les droits fondamentaux au titre de l'article 27 du règlement sur l'IA, qui la complète plutôt qu'elle ne la remplace. Les deux interagissent aussi de façon délicate. Les praticiens soulignent par exemple que le profilage au sens du RGPD peut ramener dans le champ un système qu'une exemption du règlement sur l'IA semblait libérer (r/gdpr). De l'aide officielle est en route : le CEPD et la Commission européenne doivent publier des lignes directrices conjointes sur ce chevauchement début 2026 (IAPP).

UNE POSTURE DE CONFORMITÉ OPÉRATIONNELLE POUR UNE ÉQUIPE DE PME

Vous n'avez pas besoin d'une certitude que le régulateur n'a pas fournie. Vous avez besoin d'une posture défendable et documentée. Un ordre pratique :

1. Cartographiez où les données personnelles entrent dans le système : entrées, prompts, journaux, données d'entraînement, et le magasin RAG.
2. Choisissez et consignez une base légale pour chaque usage. Si vous vous appuyez sur l'intérêt légitime, réalisez le test de mise en balance plutôt que de le présumer.
3. Réalisez une AIPD avant de déployer tout ce qui profile ou décide au sujet des personnes, et gardez un humain véritablement dans la boucle pour les cas de l'article 22.
4. Minimisez et bornez dans le temps ce que le système conserve, surtout les journaux de prompts et les vecteurs.
5. Décidez la résidence des données à dessein. Si des données personnelles devaient quitter l'UE, réalisez l'évaluation de transfert, ou gardez le traitement en UE ou on-prem.
6. Réexaminez la posture quand les lignes directrices conjointes du CEPD et de la Commission arriveront en 2026.

Version courte : très peu de choses en matière d'IA sont catégoriquement interdites sous le RGPD, quelques-unes le sont réellement, et l'essentiel du reste est un « oui, si » documenté. Les conditions qui en décident sont surtout architecturales, ce qui signifie qu'elles vous appartiennent. Les mêmes questions de gouvernance surgissent dès qu'un agent interne touche aux données d'un client (iiterate). Ceci reste une orientation plutôt qu'un conseil juridique, alors faites de votre délégué à la protection des données le prochain lecteur.

La scène européenne des modèles, Mistral et les acteurs qui l'entourent, dispose en 2026 d'argent réel et de modèles réels. Elle reste toutefois en retrait de la frontière américaine et chinoise sur la capacité brute, et le mot « européen » sur une étiquette ne signifie pas en soi « souverain ». Pour une entreprise du Mittelstand, la vraie question n'est donc pas de savoir s'il existe un modèle européen. C'est quel type de contrôle vous devez réellement obtenir, et ce qui vous le procure. Cet article expose le paysage, les lacunes réelles et la décision qui se cache derrière.

Ce que « souverain » signifie vraiment, et ce que ce n'est pas

L'IA souveraine signifie que le modèle et ses données restent sous le contrôle juridique et opérationnel d'une seule organisation. Les leviers qui la rendent effective sont concrets : des poids ouverts que vous pouvez héberger vous-même, et un hébergement qui garde les données dans l'UE ou sur vos propres machines.

Deux réserves honnêtes empêchent le mot de devenir un argument marketing.

🔸 Un code postal européen n'est pas à lui seul une garantie de souveraineté.
Des lois d'accès étatiques, en France comme en Allemagne, peuvent contraindre à divulguer des données d'une manière qu'une localisation dans l'UE ne protège pas entièrement. L'emplacement des données est nécessaire, mais pas suffisant.

🔸 La propriété compte autant que l'origine.
Silo AI, le créateur finlandais des modèles ouverts Poro et Viking, est désormais une filiale d'AMD, une société américaine, ce qui le place sous le droit américain. Un modèle né en Europe mais sous propriété étrangère n'est pas automatiquement souverain (North Atlantic).

La souveraineté est donc une question relative à la stack et à sa propriété, pas un drapeau sur une page d'accueil.

Mistral, et l'argent qui a rendu l'Europe sérieuse

Mistral est la raison pour laquelle l'IA européenne a cessé d'être une note de bas de page, et la manière dont son financement s'est constitué est le vrai signal.

Lors de sa levée annoncée en septembre 2025, Mistral a réuni environ 1,7 milliard d'euros pour une valorisation d'environ 11,7 milliards d'euros, et l'investisseur principal était ASML, le fabricant néerlandais d'équipements pour puces, apportant près de 1,3 milliard d'euros (CNBC). Qu'une entreprise qui vend les machines servant à fabriquer les puces avancées prenne une participation dans un laboratoire de modèles relève d'une manœuvre de souveraineté, pas seulement financière. Mistral l'a couplée à des infrastructures, en visant environ 200 mégawatts de puissance de calcul européenne d'ici 2027, détenue plutôt que louée, répartie sur des sites près de Paris et une grande construction neuve en Suède (Data Center Dynamics). Sa traction en entreprise est réelle également, avec des travaux nommés aux côtés d'Airbus, BMW, Amazon et SAP.

Le récit que Mistral fait de lui-même est la partie utile : il ne cherche pas à gagner la course au modèle brut contre les géants américains, il cherche à posséder la stack européenne qui se trouve sous les modèles. Pour un acheteur soucieux de contrôle, ce cadrage compte davantage qu'une place au classement.

Et au-delà : le reste du banc européen

Mistral n'est pas tout le terrain, et les autres révèlent des paris différents sur l'endroit où se situe la valeur européenne.

Aleph Alpha, l'entreprise de Heidelberg autrefois présentée comme l'espoir allemand du modèle de frontière, a cessé de courir après la frontière et s'est reconstruite autour d'une plateforme de souveraineté et de conformité, PhariaAI, destinée au déploiement on-premise et air-gapped dans les secteurs réglementés (analyse). Black Forest Labs, fondée à Fribourg par une partie de l'équipe d'origine de Stable Diffusion, crée la famille ouverte de modèles d'image FLUX (Dakota). Et Teuken-7B, issu du consortium OpenGPT-X mené par Fraunhofer, est un modèle librement téléchargeable entraîné sur les vingt-quatre langues officielles de l'UE, conçu pour être auto-hébergé (Fraunhofer).

Le motif à remarquer est que les positions européennes les plus solides portent de plus en plus sur la stack, l'ouverture et le modèle de déploiement, plutôt que sur un unique modèle de frontière. C'est précisément là que se situe l'avantage d'un acheteur du Mittelstand.

L'écart de capacité, sans complaisance

La sobriété est plus crédible que l'enthousiasme, alors voici l'écart sans détour. Sur les indices de capacité indépendants, le fleuron européen se situe autour du milieu du peloton des modèles à poids ouverts plutôt qu'à la frontière (Artificial Analysis). Le financement est déséquilibré lui aussi : le financement cumulé des modèles européens est faible à côté de la valorisation d'un seul laboratoire américain, plus proche d'une erreur d'arrondi que d'une rivalité (North Atlantic).

Le bon réflexe n'est pas de nier l'écart, mais de se demander s'il concerne votre travail. Pour la rédaction, l'extraction, la classification et la recherche dans vos propres documents, un modèle ouvert de milieu de peloton que vous contrôlez entièrement passe généralement la barre, et le contrôle vaut plus que les quelques derniers points de benchmark. C'est le même arbitrage que nous avons tiré lorsqu'un modèle de frontière a disparu d'un marché en soixante-douze heures : le contrôle opérationnel l'emporte sur la capacité louée dès lors que la capacité que vous louez peut vous être retirée (iiterate). La frontière est l'endroit où les modèles européens accusent vraiment un retard. C'est aussi la partie du travail dont bien des entreprises n'ont en réalité pas besoin.

Ce que cela signifie pour un acheteur du Mittelstand

La décision n'est pas patriotique, elle est architecturale. Trois voies pratiques, selon ce dont la charge de travail a besoin :

1. Besoin de capacité de frontière, données non sensibles. Un modèle de frontière hébergé reste l'option la plus capable. Utilisez-le, et acceptez la dépendance en connaissance de cause.
2. Le contrôle est l'enjeu. Pour des données réglementées, la confidentialité client, ou tout ce que vous devez pouvoir auditer, auto-hébergez un modèle européen ouvert ou à poids ouverts, ou utilisez de l'inférence hébergée dans l'UE, et inscrivez la résidence des données et la propriété dans le cahier des charges, pas dans le marketing.
3. Jugez la souveraineté à la stack, pas au drapeau. Où tournent les poids, où résident les données, qui peut en imposer l'accès, et si vous pouvez remplacer le modèle. La même question de contrôle sous-tend le RGPD (iiterate).

La scène européenne est enfin assez réelle pour constituer une réponse sérieuse au second cas, qui représente l'essentiel de ce qu'on nous demande de construire. La raison de s'y intéresser n'est pas le drapeau. C'est que la capacité louée est révocable et que le contrôle est quelque chose que l'on construit. La question à retenir n'est pas de savoir si l'Europe peut égaler la frontière cette année. C'est de savoir lesquelles de vos charges de travail ont vraiment besoin de la frontière, et lesquelles n'ont besoin que d'un modèle capable que vous contrôlez.