Dieser Beitrag sammelt die Anwendungsfälle, bei denen Latenz nicht Komfort ist, sondern Bedingung, und beschreibt, woran sie bisher gescheitert sind.

Warum Doom das bessere Argument ist als der Benchmark

Ein Spiel liefert die Bedingungen, die ein Benchmark verschweigt. Der Aktionsraum ist fest und klein. Der Zustand ist vollständig beschreibbar. Und es gibt ein hartes Zeitfenster, in dem geantwortet sein muss, sonst ist die Antwort wertlos, egal wie gut sie ist.

Genau an dieser Stelle scheitert ein Token-für-Token-Modell nicht an Intelligenz, sondern an Verfahren. Der Nachweis ist deshalb keine Spielerei: Wer zeigt, dass eine Entscheidung in ein Frame-Budget passt, hat gezeigt, dass sie auch in ein Zahlungsvorgang-Budget passt.

Die Spiele-Projekte als Belastungstest

Die Community hat das schnell durchdekliniert. typesafe-snake lässt den Code die legalen Züge erzeugen und das Modell einen davon je Tick wählen. jev-plays-pokemon-red läuft auf einem Emulator und ruft das Modell nur an Verzweigungen auf, mit Brier-Scores auf den eigenen Vorhersagen als Qualitätsmaß. Dazu kommen Mario-, Drohnen- und Fahr-Demos, mehrere davon in unter einer Stunde gebaut.

Der Blitzschach-Test ist die klarste Zahl aus dieser Gruppe. Jev antwortete in rund 2,6 Sekunden je Zug, während Vergleichsmodelle 6 bis 15 Sekunden brauchten und aus gewonnener Stellung auf Zeit verloren. Die Zugqualität war nicht der entscheidende Faktor, die Einhaltung des Budgets war es.

Handel, Sprachagenten und Browser-Automatisierung

Dieselbe Eigenschaft trägt Anwendungen ohne Spielcharakter. jev-trader baut eine Marktentscheidungsschleife im Sub-Sekunden-Bereich und dokumentiert Trocken- und Echtbetrieb getrennt. QuantDinger setzt das Modell als Vorprüfung vor einen Einstieg und blockiert abgelehnte Aufträge, mit protokolliertem Rückfallpfad.

Bei Sprachagenten geht es um die Entscheidung, ob unterbrochen werden darf und wann eine Antwort beginnt. Das muss im Rhythmus eines Gesprächs passieren, also deutlich unter einer Sekunde. Browser-Automatisierung hat dasselbe Profil: Welches Element ist gemeint, aus einer sichtbaren Menge, sofort. Für gesprochene Navigation werden rund 0,0002 US-Dollar je Entscheidung bei etwa 300 Millisekunden berichtet.

Was das für gewöhnliche Systeme bedeutet

Die meisten B2B-Systeme haben kein Frame-Budget, aber sie haben Budgets, die niemand aufgeschrieben hat. Ein Zahlungsvorgang darf nicht auf eine Betrugsbewertung warten. Eine Suchanfrage darf nicht auf die Neusortierung ihrer Treffer warten. Ein Assistent, der drei Sekunden braucht, wird nicht benutzt, egal wie gut die Antwort ist.

Diese Budgets waren bisher der Grund, warum Prüfungen weggelassen wurden. Fällt die Begründung weg, fällt auch der Grund weg. Wie sich ein Antwortzeitbudget für einen KI-Assistenten überhaupt aufteilt, haben wir in Antwortzeit eines KI-Assistenten beschrieben.

Die harten Grenzen im Echtzeitbetrieb

Ein Auswahlaufruf trägt bis zu 255 Optionen, eine Skala 2 bis 10 Stufen. Die Ratengrenzen liegen bei rund 250.000 Tokens je Sekunde und 1.200 Anfragen je Minute und sind laut Anbieter dynamisch. Für eine Schleife, die zehnmal je Sekunde entscheidet, ist die Anfragegrenze und nicht die Latenz der bindende Faktor.

Und es bleibt bei Text. Kein Bild, kein Audio, kein Video. Wer einen Spielzustand oder eine Kameraszene bewerten lassen will, muss sie vorher in eine Zustandsbeschreibung übersetzen. Diese Übersetzung ist die eigentliche Ingenieursarbeit, nicht der Modellaufruf.

Dieser Beitrag beschreibt sechs davon und benennt jeweils die Fragen, aus denen die Entscheidungsschicht besteht. Es sind Muster, keine fertigen Systeme.

Rechnungsabgleich und Eingangsprüfung

Eine eingehende Rechnung wird gegen Bestellung, Vertrag, Lieferantenstammdaten und Liefernachweis gehalten. Die Fragen sind unabhängig voneinander: Stimmt die Position mit der Bestellung überein, liegt der Preis im vertraglich vereinbarten Rahmen, ist der Lieferant bekannt, existiert ein Liefernachweis. Jede Frage bekommt eine eigene Wahrscheinlichkeit, und erst der Code verrechnet sie zu einer Freigabe.

Das ist der Unterschied zu einem einzigen Modellaufruf, der "prüfe diese Rechnung" fragt. Vier getrennte Urteile lassen sich einzeln nachvollziehen und einzeln nachjustieren. Ein zusammengefasstes Urteil nicht.

Reisekosten und Spesenfreigabe

Ein Spesenbeleg wird zunächst auf Lesbarkeit geprüft, dann klassifiziert, dann gegen die Reisekostenrichtlinie gehalten. Bewirtungsbelege sind der Fall, an dem die meisten Automatisierungen scheitern, weil die Regel selten eindeutig ist und der Betrag allein nicht reicht.

Als Fragensatz funktioniert das gut: Ist der Beleg lesbar, welche Kategorie, überschreitet der Betrag die Grenze für diese Kategorie, fehlt eine erforderliche Angabe. Was unterhalb der Konfidenzschwelle liegt, geht an einen Menschen, und zwar mit der Angabe, welche der vier Fragen unsicher war.

Schadensmeldungen und Erstbewertung

In der Erstbewertung einer Schadensmeldung existiert meist bereits eine Prüfliste. Sie wird heute entweder von Hand abgearbeitet oder in ein Formular gepresst. Als Satz unabhängiger Ja-Nein-Fragen auf demselben Vorgang bleibt jede Einzelwahrscheinlichkeit erhalten, statt zu einer Ampel zusammenzufallen.

Der operative Gewinn liegt nicht in der Automatisierung der Entscheidung, sondern in der Reihenfolge. Fälle, bei denen alle Fragen eindeutig sind, kommen zuerst durch. Fälle mit einer unsicheren Antwort landen vorne in der menschlichen Warteschlange statt hinten.

Prüfberichte und regulatorische Durchsicht

Ein Dokument gegen einen Anforderungskatalog zu halten ist ein Stapel unabhängiger Fragen auf einem Zustand. Vertragsklauseln gegen eine Vorgabenliste, ein Prüfbericht gegen eine Norm, eine Dokumentation gegen eine Checkliste. Das Modell beantwortet jede Anforderung einzeln, der Bericht entsteht im Code.

Wichtig ist die Grenze: Das Ergebnis ist eine Vorsortierung, keine Bewertung. Wer eine Begründung braucht, braucht einen Menschen oder ein generierendes Modell, und warum das nicht dasselbe ist, steht in Eine Zahl ohne Begründung.

Sicherheitsmeldungen und Alarmkontext

Eine Sicherheitsmeldung wird mit dem Kontext zusammengeführt, in dem sie entstanden ist, und dann auf drei Dinge geprüft: War die Handlung autorisiert, gibt es eine harmlose Erklärung, wie stark ist die Beweislage. Die dritte Frage ist die wichtigste, weil sie darüber entscheidet, ob überhaupt jemand geweckt wird.

Dasselbe Muster trägt die Durchsicht abgeschlossener Agentenläufe, wenn ein Unternehmen KI-Agenten auf eigene Systeme lässt. Rechteüberschreitung, Aufgabenerfüllung, Auffälligkeit, je als eigene Frage.

Extraktion mit Kontrolle statt Extraktion allein

Das wirksamste Muster für Dokumenten-Pipelines ist eine Kaskade. Ein kleines, günstiges Modell extrahiert die Felder. Eine typisierte Entscheidungsschicht prüft jeden Wert einzeln gegen den Quelltext. Nur was durchfällt, geht an ein größeres Modell oder an einen Menschen.

Damit verschiebt sich die Qualitätsfrage von "wie gut extrahiert das Modell" zu "wie zuverlässig erkennen wir einen falschen Wert". Die zweite Frage ist messbar, die erste war es nie. Welche Fehlerbilder in Dokumentenstrecken typisch sind, behandelt Wo ein KI-Feature schiefgeht.

Dieser Beitrag geht durch die öffentlichen Projekte, die seit dem 15. September entstanden sind, und benennt das wiederkehrende Muster dahinter. Die Sammlungen liegen offen, unter anderem als awesome-jev und awesome-jev-by-typesafe.

Triage ist der erste Reflex

Die naheliegendste Anwendung ist ein Posteingang, der sortiert werden muss. TypeSafe selbst zeigt das an einem Triage-Dashboard für GitHub-Repositories: Zu jedem Issue beantwortet das Modell denselben festen Fragensatz, also Art, Schwere, Dringlichkeit, Duplikat und nächster Schritt. Unsichere Fälle und Stellen, an denen Menschen widersprochen haben, bekommen eigene Aufmerksamkeit, und jede menschliche Korrektur wird aufbewahrt und bei späteren Läufen wieder mitgegeben.

Dasselbe Muster trägt den Support-Posteingang. Der Code sammelt Vorgang und Geschäftsregeln ein, das Modell beantwortet Kategorie, Dringlichkeit und Frustrationsgrad, und die Zuweisung an eine Warteschlange bleibt gewöhnlicher Code. Die Reihenfolge ist wichtig: erst die Warteschlangen verbessern, dann automatisieren.

Retrieval, Suche und die Prüfung von Behauptungen

Die zweite große Gruppe sitzt vor oder hinter einer Suche. jev-reranker ist eine Rust-Kommandozeile, die Treffer mit Ja-Nein-Fragen neu ordnet, filtert und kürzt. nlgrep sucht in Dateien nach einer in natürlicher Sprache formulierten Bedingung und gibt gerankte Dateien mit Fundstellen zurück. jevql schiebt dieselben Fragen als Filter und Sortierung in eine Postgres-Abfrage.

Aufschlussreicher als die Werkzeuge ist die Fragenliste, die sich eingebürgert hat. Ein abgerufener Abschnitt wird nicht nur auf Relevanz geprüft, sondern auch darauf, ob er die Antwort stützt, ob er ihr widerspricht und ob er eine eingeschleuste Anweisung enthält. Vier unabhängige Urteile auf demselben Zustand, in einem Aufruf.

Code, Commits und CI als Entscheidungsproblem

Eine überraschend dichte Gruppe sitzt in der Entwicklungskette selbst. jev-git prüft gestagte Diffs vor dem Commit auf Geheimnisse und zerstörerische Kommandos. is-malicious bewertet Quell-, Konfigurations- und CI-Dateien, wobei Schwellenwerte und Schweregrade im Code bleiben. jev-pref liest Projektkonventionen aus einer AGENTS.md und prüft Diffs dagegen, also semantisches Linting statt Formatprüfung.

Der gemeinsame Nenner: Regeln, die bisher als Regex oder als Kommentar im Pull Request existierten, werden zu Ja-Nein-Fragen, die auf jedem Commit laufen können, weil sie nichts kosten.

Agenten, die ihre eigenen Schritte bewerten

Die interessanteste Gruppe steuert andere KI-Systeme. JevRouter wählt aus einer Menge von Fähigkeiten aus, während Verfügbarkeit, Rechte und Fallback im Code bleiben. jev-guard bewertet geplante Werkzeugaufrufe nach Risiko und gibt sie frei, fragt nach oder verweigert. wakegate entscheidet vor dem Fortsetzen eines schlafenden Agenten, ob ein Ereignis überhaupt zu ihm gehört.

Beobachtbarkeit gehört in dieselbe Gruppe. jevlogs annotiert OpenTelemetry-Datensätze und überspringt teure Analyse für Spuren ohne Aussagewert. Ein abgeschlossener Agentenlauf lässt sich im Nachhinein auf Rechteüberschreitungen, Aufgabenerfüllung und Zufriedenheit prüfen, ohne dass ein Mensch ihn liest.

Zahlen, die aus echten Läufen stammen

Ein paar Projekte veröffentlichen ihre eigenen Messungen, und die sind belastbarer als jeder Anbieter-Benchmark. jev-skip, eine Browser-Erweiterung, die Sponsoren-Abschnitte in YouTube-Videos anhand der Untertitel erkennt, meldet eine Trefferquote von 77 Prozent der Sponsoren-Sekunden über 23 Videos bei 0,0008 US-Dollar je Video. Eine Audit-Studie mit 1.204 gecrawlten Seiten kam auf 4.816 typisierte Urteile je Lauf und 0,0048 US-Dollar je Triage-Stapel aus zwölf Fragen.

Die Zahl, die im Alltag zählt, ist nicht der Faktor gegenüber einem Sprachmodell, sondern die Absolutkosten je Entscheidung. Bei diesen Größenordnungen verschwindet die Frage, ob eine Prüfung sich lohnt.

Das Muster hinter allen Projekten

Fast jedes dieser Projekte trennt gleich. Das Modell beantwortet eine enge Frage über einen übergebenen Zustand. Der Code besitzt die Optionsmenge, den Schwellenwert, die Rechte, die Reihenfolge und den Fallback. Wo ein Projekt diese Trennung aufgibt und das Modell entscheiden lässt, was es tun darf, taucht im Repository kurz darauf eine Ausnahmebehandlung auf.

Die zweite Wiederkehr ist die Bündelung. Statt fünf Aufrufe nacheinander zu machen, werden alle plausibel benötigten Fragen in einem Aufruf gestellt, auch die, deren Antwort vielleicht gar nicht gebraucht wird. Bei kostenlosen Ausgabe-Tokens ist das billiger als die zweite Netzwerkrunde. Was das für den Entwurf einer Pipeline bedeutet, steht in Wo ein Entscheidungsmodell tatsächlich hingehört.

Für alles, was den Antrag, den Anspruch, die Rechnung oder das Arbeitsverhältnis eines Menschen berührt, wirkt die fehlende Begründung zunächst wie das eigentliche Problem. Sie ist es nicht. Sie ist eine Aussage darüber, wo der Nachweis liegen muss.

Die generierte Begründung war nie ein Nachweis

Ein Sprachmodell, das einen Fall klassifiziert, kann um eine Begründung gebeten werden, und die liest sich gut. Genau darin liegt die Falle. Der Text entsteht im Nachhinein und ist kein Protokoll der Berechnung, die zur Entscheidung geführt hat. Er ist eine plausible Geschichte über eine Entscheidung, nicht die Entscheidung. Abgelegt wurde er trotzdem als Prüfspur.

Ein Entscheidungsmodell nimmt diese Illusion weg. Es liefert eine typisierte Ausgabe und eine kalibrierte Wahrscheinlichkeit, und nichts, was einer Begründung ähnelt. Der Nachweis muss also um das Modell herum gebaut werden statt von ihm angefordert.

Wie der Nachweis aussieht

In der Praxis protokolliert die Entscheidungsschicht den übergebenen Zustand, die exakt gestellte Frage, die typisierte Antwort, die Wahrscheinlichkeit, den zu diesem Zeitpunkt geltenden Schwellenwert und die Version des Fragensatzes. Das ist reproduzierbar. Bei gleichem Zustand lässt sich zeigen, was das System gefragt wurde und was es zurückgegeben hat. Ein generierter Absatz kann das nicht leisten.

Der Fragensatz selbst wird damit zum versionierten Artefakt. Ändert sich eine Frage, ändert sich die Grundlage aller späteren Entscheidungen, und das muss sichtbar sein. In Systemen, die wir bauen, liegt dieser Satz im Repository und nicht in einer Konfigurationsoberfläche.

Kalibrierung verdient einen präzisen Satz

Kalibrierung ist eine Eigenschaft einer Verteilung. Gibt das Modell über viele Fälle hinweg 0,8 an, sind davon etwa acht von zehn korrekt. Über den konkret vorliegenden Fall sagt das nichts.

Der Schwellenwert ist damit eine Richtungsentscheidung über akzeptierten Fehler und gehört in ein Dokument, das ein Mensch unterzeichnet hat, nicht in eine Konstante im Quellcode. Teams, die das ernst nehmen, messen die Kalibrierung auf einem zurückgehaltenen Teil der eigenen Daten nach, statt sie vorauszusetzen.

Aufsicht braucht Grenzen, keinen Fließtext

Die Anforderungen des EU AI Act an menschliche Aufsicht bei höherem Risiko zeigen in dieselbe Richtung. Aufsicht ist dann wirksam, wenn die prüfende Person sieht, was das System bekommen hat, was es entschieden hat und wo die Grenze liegt. Ein selbstbewusster Satz, erzeugt von genau dem System, das die Entscheidung getroffen hat, leistet das nicht. Ein protokollierter Zustand mit Frage, Score und Schwellenwert leistet es.

Es gibt eine Variante, die schlechter ist als beide Optionen. Ein Entscheidungsmodell liefert eine Zahl, und ein Sprachmodell wird anschließend gebeten, diese Zahl zu erklären. Das wirkt gründlich und ist es nicht. Die Erklärung wird aus der Ausgabe rekonstruiert, nie aus der Berechnung.

Die Form, auf die wir hinbauen

Typisierte Entscheidungen dort, wo die Antwort eine Klasse, ein Score oder ein Boolescher Wert ist. Generierung nur dort, wo ein Mensch tatsächlich Fließtext braucht. Ein Entscheidungsnachweis, der außerhalb von beidem liegt und nicht davon abhängt, dass eines von beidem einsehbar ist. Menschliche Prüfung ausgelöst durch das Wahrscheinlichkeitsband statt durch das Thema, damit die Fälle nahe der Grenze Aufmerksamkeit bekommen und nicht die Fälle, die jemand für heikel gehalten hat.

Als Prinzip ist daran nichts neu. Neu ist, dass die Entscheidungsschicht günstig genug geworden ist, damit sich die Architektur auch in gewöhnlichen B2B-Workloads lohnt und nicht nur in Systemen, an denen ohnehin eine Aufsichtsbehörde hängt.

Ein Entscheidungsmodell ersetzt nicht das Sprachmodell im Stack. Es ersetzt die Sprachmodell-Aufrufe, die nie wirklich Sprachaufgaben waren. Dieser Beitrag benennt fünf solche Stellen und beschreibt einen Test, der ohne Business Case auskommt.

Klassifikation beim Eingang

Jede Dokumenten-Pipeline beginnt mit der Entscheidung, was überhaupt eingegangen ist. Rechnung, Lieferschein, Vertragsnachtrag oder etwas Unlesbares, das einen Menschen braucht. Die meisten Teams lösen das mit einem kleinen Modellaufruf plus JSON-Schema und härten anschließend wochenlang den Parser.

Eine typisierte Auswahl mit Konfidenzwert eliminiert das Parsing-Problem vollständig, weil die Ausgabe nie Text war. Der Schwellenwert, ab dem ein Fall an einen Menschen geht, wird damit zu einer eingestellten Größe statt zu einer Heuristik im Code.

Filterung im Retrieval

Bei Retrieval Augmented Generation ist nicht der fehlende Textabschnitt der teure Fehler, sondern der irrelevante, der zu einer selbstbewusst falschen Antwort synthetisiert wird. Jeden Kandidaten vor der Synthese auf tatsächliche Relevanz zu bewerten ist der wirksamste Guardrail der Pipeline und wird am häufigsten weggelassen, weil ein Sprachmodell dafür einen zusätzlichen Aufruf pro Abschnitt bedeutet.

Im Sub-Cent-Bereich bewertet man alle, und zwar nicht nur auf Relevanz: ob der Abschnitt die Antwort überhaupt stützt, ob er der Frage widerspricht, ob er eine eingeschleuste Anweisung enthält. Das sind vier Nouls auf demselben Zustand. Wie dieselbe Schicht in der Praxis eingesetzt wird, zeigt Was Entwickler mit Jev tatsächlich bauen.

Tool- und Routing-Auswahl

Agentische Systeme verbringen einen überraschend großen Teil ihres Latenzbudgets mit der Entscheidung, welches Werkzeug als Nächstes aufgerufen wird. Diese Entscheidung ist eine Auswahl aus einer festen Menge. Sie braucht keine Begründung, sie muss richtig und schnell sein.

Der belastbare Teil des Musters liegt in der Trennung der Achsen: Die Antwort sagt, was gewählt wurde, die Konfidenz sagt, wie sicher. Eine umkehrbare Aktion darf bei geringer Konfidenz laufen, eine unumkehrbare nicht. Damit wird aus einem Modellaufruf eine Freigabelogik, die im Code liegt und dort auch geprüft werden kann.

Prüfung der Extraktion und Guardrails

Nach der Extraktion eines Feldes muss etwas beurteilen, ob es vollständig und plausibel wirkt. Teams überspringen das, prüfen stichprobenartig oder leiten alles an einen Menschen weiter. Ein kalibrierter Score pro Feld macht daraus einen Schwellenwert, den man gegen ein reales Fehlerbudget einstellen kann statt gegen ein Bauchgefühl.

Policy-Prüfungen sind ebenfalls Klassifikationen. Üblicherweise laufen sie nur auf Anfragen, die jemand als riskant markiert hat, weil sie überall zu langsam und zu teuer waren. Diese Einschränkung entfällt weitgehend.

Wie man es ohne Business Case testet

Einen Monat produktiver Klassifikationsaufrufe nehmen und erneut abspielen. Genauigkeit und p95-Latenz gegen den heutigen Stand vergleichen. Dann nicht den Gesamtscore ansehen, sondern die Abweichungen, denn die Abweichungen zeigen, ob die Aufgabe jemals eine Sprachaufgabe war. Der Test kostet weniger als das Meeting darüber, ob man ihn durchführt. Die Schnittstelle dafür liegt bereits in gängigen Werkzeugketten, etwa als evaluate-Aufruf im AI SDK.

Der größere operative Gewinn steckt nicht in der Inferenzersparnis. Die meisten B2B-KI-Pipelines haben dünne Observability, weil die Bewertung jedes Schritts einen weiteren Modellaufruf kostet und dafür niemand Budget einplant. Sinkt die Bewertung auf einen Rundungsfehler, lässt sich jeder Schritt jedes Laufs bewerten, die Verteilung festhalten und Drift erkennen, bevor ein Nutzer sie meldet.

Nicht geeignet ist das Muster für alles, was eine Begründung liefern, an einen Menschen schreiben oder über den übergebenen Zustand hinausgreifen muss. Ein Entscheidungsmodell hat kein Weltwissen und keine Begründung. Arbeit dieser Art dorthin zu geben ist der Weg, auf dem ein erster Pilot scheitert.

Dieser Beitrag ordnet die These ein, benennt die belastbaren Zahlen und die Grenzen, und beschreibt, was daraus für die Architektur von B2B-Pipelines folgt.

Die Benennung ist die These

"System One" übernimmt die Trennung von Daniel Kahneman zwischen schnellem, intuitivem Urteil und langsamem, bewusstem Schlussfolgern. Das Modell selbst ist nach William Stanley Jevons benannt, dem Ökonomen hinter dem Jevons-Paradoxon: Wird eine Ressource billiger, steigt der Gesamtverbrauch, statt zu sinken. TypeSafe sagt damit offen, was passieren soll, sobald eine Entscheidung einen Bruchteil eines Cents kostet.

Die architektonische These trifft etwas, das in fast jeder B2B-Pipeline sichtbar ist. Die meisten Entscheidungen innerhalb eines Produktivsystems sind keine System-2-Probleme. Ist dieses Dokument eine Rechnung oder ein Lieferschein. Braucht dieses Ticket einen Menschen. Ist dieser abgerufene Textabschnitt für die gestellte Frage überhaupt relevant. Wirkt dieses extrahierte Feld vollständig. Das sind Klassifikationen, gelöst mit Modellen, die für Konversation gebaut sind, zu Konversationslatenz und Konversationspreisen.

Drei Fragetypen, mehr gibt es nicht

Die gesamte Schnittstelle besteht aus drei Primitiven. Noul beantwortet eine Ja-Nein-Frage mit einer Wahrscheinlichkeit zwischen 0 und 1. Choice wählt eine Option aus einer festen Menge von bis zu 255 Einträgen und liefert die vollständige Verteilung mit. Score ordnet auf einer Skala von zwei bis zehn Stufen ein und gibt einen wahrscheinlichkeitsgewichteten Mittelwert zurück.

Zustand und Fragen teilen sich ein Budget von rund 64.000 Tokens, wobei Zustand plus längste Einzelfrage bei etwa 32.000 Tokens liegen müssen. Nur Text, keine Bilder, kein Audio, kein Video. Die Enge dieser Schnittstelle ist kein Mangel, sondern der Punkt: Was zurückkommt, muss nicht geparst werden, weil es nie Text war.

Herstellerzahlen bleiben Herstellerzahlen

TypeSafe nennt bis zu 193-fach schneller und 444-fach günstiger als Frontier-Modelle bei eng gefassten Entscheidungsaufgaben. Das sind Benchmarks des Anbieters auf Aufgaben, die der Anbieter ausgewählt hat. Eine unabhängige Bestätigung der Größenordnung wird Monate dauern, und eng gefasste Benchmark-Aufgaben sind der freundlichste denkbare Fall für ein Entscheidungsmodell.

Die Richtung steht trotzdem kaum infrage, und der Markt hat das schnell deutlich gemacht. Vercel hat Jev ins AI Gateway aufgenommen und binnen weniger Tage als am schnellsten adaptierten Modell-Launch der Plattformgeschichte bezeichnet. Netlify zog nach. Ein Open-Source-CRM hat einen Pull Request gemerged, der eine völlig neue Modellkategorie einführt, "evaluation", samt darauf aufsetzendem Klassifikations-Node. Infrastruktur bewegt sich für eine marginale Verbesserung nicht so schnell.

Der eigentliche Effekt ist der zweiter Ordnung

Die meisten KI-Systeme behandeln heute jeden Schritt als Generierungsproblem, weil Generierung das einzige verfügbare Werkzeug war. Ein großes Modell übernimmt Routing, Extraktion, Bewertung und Formulierung, und die gesamte Pipeline erbt die Eigenschaften ihrer langsamsten und teuersten Komponente.

Trennt man die schnellen typisierten Entscheidungen von der langsamen generativen Arbeit, ändert sich die Form des Systems. Kostet eine Klassifikation fast nichts, hört man auf zu rationieren. Retrieval wird gefiltert statt Kontext vollgestopft. Jedes extrahierte Feld wird bewertet statt stichprobenartig geprüft. Die Policy-Prüfung läuft auf jeder Anfrage, nicht nur auf den als riskant markierten. Jevons, wie angekündigt.

Die Grenzen sind strukturell, nicht vorübergehend

Jev liefert eine Zahl ohne Begründung. Das wird relevant in dem Moment, in dem jemand fragt, warum ein Fall so geroutet wurde. Das Modell hat kein Weltwissen, es kennt ausschließlich den übergebenen Zustand. Kalibrierung ist eine Eigenschaft der Verteilung über viele Vorhersagen, keine Garantie für die einzelne Antwort. Was daraus für Nachweis und Aufsicht folgt, steht in Eine Zahl ohne Begründung.

Auch die schärfste Kritik in der Diskussion auf Hacker News verdient Beachtung. Ein großer Teil der Geschwindigkeit könnte aus eingeschränktem Single-Token-Decoding gegen eine feste Auswahlmenge stammen statt aus einer neuen Architektur. Träfe das zu, wäre der Vorteil reproduzierbar und der Burggraben schmal.

An der Lehre ändert das nichts. Entscheidungsarbeit und Spracharbeit haben unterschiedliche Kostenkurven, unterschiedliche Latenzbudgets und unterschiedliche Fehlermodi. Sie als eine Schicht zu bauen war eine Bequemlichkeit des Werkzeugs, keine Eigenschaft des Problems. Wo die Trennung in einer laufenden Pipeline konkret verläuft, beschreibt Wo ein Entscheidungsmodell tatsächlich hingehört.

Die Frage, wie groß ein solches Modell sein darf, hat keine einzelne Antwort in Megabyte. Sie hat zwei Budgets, die unterschiedlich funktionieren, und einen Posten, der fast immer unterschätzt wird.

Warum ein 3D-Modell anders lädt als ein Video

Ein Produktvideo wird einmal berechnet und dann nur abgespielt. Ein 3D-Modell im Browser zeichnet dagegen die Grafikkarte des Besuchers bei jeder Bewegung neu, aus Dreiecken für die Oberfläche und aus Texturen, also Bildern für Farbe und Material. Deshalb kann ein Kunde die Einhausung drehen oder eine andere Füllung wählen, und deshalb entscheidet sein Gerät, ob das flüssig gelingt.

Ein Konfigurator liegt zwischen zwei Extremen. Ein Video legt jedes Bild vorher fest, ein CAD-Programm lässt jedes Maß offen, und im Konfigurator stehen die Regeln fest, innerhalb derer der Kunde frei wählt.

Für die Frage nach der Größe heißt das: Die Last trägt das Gerät des Kunden. Die Grenze setzt deshalb das schwächste Gerät, mit dem Ihre Zielgruppe das Modell öffnet.

Zwei Budgets, die man getrennt rechnen muss

Das erste Budget ist die Übertragung. Geometrie, Texturen und der Programmcode für die Darstellung müssen über das Netz, und ihre Summe bestimmt zusammen mit der Bandbreite, wie lange der Kunde wartet. Verdichtungsverfahren machen die Daten für den Transport kleiner.

Das zweite Budget ist der Grafikspeicher. Um zu zeichnen, hält das Gerät Geometrie und Texturen in einer Form vor, mit der die Grafikkarte direkt arbeiten kann, und diese Form ist oft viel größer als die übertragene Datei. Reicht der Speicher nicht, ruckelt die Darstellung, oder die Seite bricht ab.

Die beiden Budgets verhalten sich unterschiedlich. Eine gut verdichtete Datei lädt schnell und kann trotzdem den Grafikspeicher eines Telefons überfordern, und eine Datei, die in den Speicher passt, kann trotzdem zu lange laden.

Warum meist die Texturen den Ausschlag geben

Die Größe einer Textur wächst mit dem Quadrat ihrer Kantenlänge. Eine Textur mit 2.048 mal 2.048 Bildpunkten hat viermal so viele Bildpunkte wie eine mit 1.024, und jedes Material trägt oft mehrere davon, etwa für Farbe, Oberflächenstruktur und Rauheit. Bei acht Materialien mit je drei Texturen sind das bereits 24 Bilder.

Hinzu kommt der Unterschied zwischen Datei und Speicher. JPG und PNG sind für die Übertragung verdichtet, die Grafikkarte kann mit diesen Formaten aber nicht zeichnen, deshalb werden sie vorher vollständig entpackt. Zusätzlich hält das Gerät meist verkleinerte Fassungen jeder Textur für entfernte Ansichten vor, was den Bedarf um rund ein Drittel erhöht.

Texturen im Format KTX 2.0 gehen einen anderen Weg. Sie werden beim Laden in ein Format umgewandelt, das die Grafikkarte auch danach verdichtet halten kann, und senken so nach Angaben der Khronos Group den Grafikspeicher. Über eine Erweiterung lassen sie sich direkt in glTF-Dateien einbetten, das gängige Lieferformat für 3D im Web.

Es ist wie bei Akten: Im Ordner brauchen sie wenig Platz, ausgebreitet auf dem Schreibtisch sehr viel. Eine JPG-Textur liegt auf der Grafikkarte ausgebreitet, eine Textur im GPU-Format bleibt im Ordner.

Rechnen Sie das Ladebudget der Einhausung nach

Der Rechner trennt beide Budgets und prüft sie gegen drei angenommene Geräteklassen. Voreingestellt ist die Einhausung, wie sie aus einem Renderprogramm kommen könnte: 900.000 Dreiecke, acht Materialien mit je drei Texturen in 2.048 Bildpunkten, JPG-Texturen und verdichtete Geometrie. Alle Werte sind Beispielwerte, auch die Annahmen zu Bandbreite und Grafikspeicher der Geräteklassen.

Achten Sie auf die Zeile Smartphone. Schalten Sie dann das Texturformat von JPG auf KTX2 und senken Sie danach die Texturauflösung auf 1.024.

In der Voreinstellung überträgt das Modell rund 25 Megabyte, davon rund 21 Megabyte Texturen, und belegt 537 Megabyte Grafikspeicher. Mit KTX2 sinkt der Grafikspeicher in der Rechnung auf 89 Megabyte, das Telefon lädt aber immer noch zu lange. Erst mit 1.024 Bildpunkten fällt die Ladezeit auf rund 7,5 Sekunden, und das Urteil wechselt auf „läuft mit Abstrichen“.

Was die Rechnung über das Beispiel verrät

Die Geometrie ist in diesem Beispiel der kleinere Posten, solange sie verdichtet wird. Verdoppeln Sie die Dreiecke auf 1,8 Millionen, wächst die Übertragung nur um rund drei Megabyte. Schalten Sie die Verdichtung aus, wird die Geometrie mit rund 25 Megabyte zum größten Posten, und schon das Notebook lädt zu lange.

Die Texturauflösung ist der stärkste Hebel. Mit 4.096 Bildpunkten vervierfachen sich die Texturen, und in der Rechnung scheitert selbst der Bürorechner an der Ladezeit. Welche Auflösung ein Material braucht, hängt davon ab, wie nah der Kunde herangehen kann: Eine Füllung aus Drahtgitter, die nie näher als einen Meter vor der Kamera erscheint, braucht keine Textur für die Lupe.

Die Rechnung ist bewusst einfach. Sie kennt keine Zeichenaufrufe, keine Schatten und kein schrittweises Nachladen, und ihre Faktoren für Verdichtung und Speicher sind Annahmen. Sie zeigt Größenverhältnisse und sagt nicht voraus, wie ein bestimmtes Modell auf einem bestimmten Gerät läuft.

Wie ein Konfigurator von innen aufgebaut ist

Das Ladebudget betrifft nur eine von sechs Stufen, die ein Modell auf dem Weg von der Konstruktion zum Kunden durchläuft. Die meisten Vorhaben stocken dabei weniger an der Grafik als am Regelwerk.

Modell. Die Geometrie braucht benannte Bauteile wie Pfosten, Tür und Füllung, Maße in Millimetern und einen festen Ursprung. Kommt das Modell als einzelnes Netz ohne benannte Teile aus einem Renderprogramm, weiß die Software nicht, wo die Tür aufhört, und jede Variante wird Handarbeit.

Regelwerk. Hier steht, welche Optionen es gibt, welche sich ausschließen und welche Grenzmaße gelten. Oft stecken diese Regeln im Kopf weniger Personen, oder Preisliste und Konfigurator führen getrennte Optionslisten, die auseinanderlaufen.

Varianten. Der eingestellte Zustand gehört an eine Stelle, die ein Link mitnehmen kann, etwa in die Adresse der Seite. Lebt er nur im Speicher des Browsers, löscht die Zurück-Taste die Auswahl, und niemand kann seine Konfiguration weiterschicken.

Preisgerüst und Stückliste. Mengen sollten aus derselben Geometrie stammen wie das Bild, sonst weicht eine getrennt gepflegte Stückliste irgendwann ab. Preisstaffeln gehören nicht in den Browser, weil jeder sie dort auslesen kann.

Darstellung. Material, Licht, Kamera, Beschriftung und Ladereihenfolge entscheiden über das Ladebudget. Dazu gehört die Entscheidung, wann nicht gezeichnet wird, denn ein endlos rotierendes Modell leert Akkus.

Ausgabe. Am Ende steht, was der Kunde abschickt: eine Anfrage mit vollständigem Zustand, eine Stückliste oder eine Datei für die Fertigung. Kommt die Anfrage ohne Konfiguration an, baut der Innendienst von Hand nach, was der Kunde schon eingestellt hatte.

Wie eine parametrische Definition als Dienst hinter einem solchen Konfigurator laufen kann, beschreibt Vom Grasshopper-Modell zum Web-Konfigurator. Zwei Rechner, die Mengen und Dateien aus einer Regel ableiten, sind der Fassaden-Rationalisierer und der Nesting-Rechner.

Was vor dem Export geklärt sein sollte

Die meisten Größenprobleme entstehen beim Export, und die meisten lassen sich mit wenigen Entscheidungen davor vermeiden. Nach Wirkung sortiert sind es sechs.

1. Die schwächste Geräteklasse der Zielgruppe festlegen und beide Budgets für sie rechnen.
2. Die Texturauflösung je Material nach dem kleinsten Betrachtungsabstand wählen.
3. Texturen zwischen Materialien teilen und wiederholen, statt jede Fläche einzeln zu bemalen.
4. Ein GPU-taugliches Texturformat prüfen, wenn der Grafikspeicher knapp ist.
5. Geometrie für die Auslieferung verdichten und Details entfernen, die aus Betrachtungsabstand nicht sichtbar sind, etwa Gewinde, Schrauben und innenliegende Teile.
6. Die Browserfassung automatisch aus der Konstruktion ableiten, statt sie von Hand nachzubauen.

Der letzte Punkt entscheidet über die Pflege. glTF ist nach Beschreibung der Khronos Group ein Format für die effiziente Übertragung und das Laden von 3D-Szenen, also ein Lieferformat und kein Arbeitsformat. Wird die Browserfassung bei jeder Konstruktionsänderung neu erzeugt, bleibt sie aktuell, während ein von Hand nachgebautes Modell mit der ersten Änderung auseinanderläuft.

Wann ein Bild die bessere Wahl ist

Gibt es ein Produkt nur in wenigen Ausführungen, sind gute Fotos in Herstellung und Pflege günstiger als jedes 3D-Modell. Ob sich ein parametrisches Modell lohnt, hängt an Variantenzahl und Änderungshäufigkeit, wie Wann sich ein parametrisches Modell rechnet ausführt.

Nutzt die Zielgruppe vor allem ältere Telefone oder langsame Verbindungen, ist ein vorab berechnetes Bild oder ein kurzes Video robuster. Und fehlt ein sauberes Konstruktionsmodell, zeigt ein Konfigurator ungeprüfte Maße, nach denen womöglich jemand bestellt.

Ob ein Kunde das Modell zusätzlich im eigenen Raum sehen sollte, ist eine eigene Frage. Wann eine Maßprüfung genügt und wann AR hilft, behandelt Passt es in den Raum?, die Leistung selbst beschreibt die Seite 3D-Konfiguratoren.

Der naheliegende Plan heißt Neubau und Umstellung an einem festen Tag. Der andere Plan zieht die Module einzeln um, lässt Alt und Neu eine Zeit lang nebeneinander laufen und schaltet das Altsystem erst ab, wenn nichts mehr darauf zugreift. Welcher Plan trägt, hängt weniger an der Technik als an den Abhängigkeiten zwischen den Modulen, und die lassen sich vorher aufschreiben und durchrechnen.

Warum ein Stichtag so viel auf einen Tag legt

Bei einer Umstellung an einem Stichtag passiert alles gleichzeitig: Die Daten werden übertragen, alle Schnittstellen zeigen auf das neue System, alle Nutzer arbeiten ab Montag in neuen Masken. Jeder dieser Schritte kann einzeln gelingen und im Zusammenspiel trotzdem scheitern, und der Fehler zeigt sich erst, wenn der erste echte Auftrag durchläuft.

Ein Stichtag gleicht dem Umzug einer Werkhalle an einem Wochenende. Klemmt am Montag eine Maschine, steht die ganze Halle, weil die alte Aufstellung bereits abgebaut ist. Dazu kommt, dass sich eine Umstellung schwer zurücknehmen lässt, sobald im neuen System die ersten Belege entstanden sind: Wer zurückschaltet, muss diese Daten wieder in das Altsystem bringen.

Daraus folgt nicht, dass ein Stichtag immer falsch ist. Es folgt, dass das Risiko eines Stichtags mit der Zahl der Module wächst, die an diesem Tag gemeinsam funktionieren müssen. Genau diese Zahl lässt sich mit einer schrittweisen Ablösung klein halten.

Eine Weiche vor dem Altsystem

Martin Fowler beschreibt das Vorgehen unter dem Namen Strangler Fig, nach einer Feige, die an einem Wirtsbaum emporwächst, bis sie ihn ersetzt. Neue Funktionen entstehen getrennt vom Altsystem, beide laufen während des Übergangs nebeneinander, und das Verhalten wandert schrittweise vom alten in das neue System. Fowler betont, dass die Zerlegung in einzeln ersetzbare Teile der eigentliche Kern ist.

Technisch braucht das eine Stelle, an der sich entscheiden lässt, welches System eine Anfrage bearbeitet. Das kann eine vorgeschaltete Schnittstelle sein, über die Portal, Lager und Buchhaltung ohnehin sprechen, oder eine Datenbanksicht, hinter der die Tabellen umgezogen werden. Diese Weiche ist Übergangsarchitektur: Sie kostet Aufwand, obwohl sie am Ende wieder verschwindet, und sie ist trotzdem der Grund, warum jeder einzelne Umzug klein bleibt.

Fehlt eine solche Stelle, weil Nutzer und Fremdsysteme direkt in die Datenbank des Altsystems schreiben, beginnt die Ablösung mit ihrem Bau. Dieser erste Schritt bringt fachlich noch nichts Neues, er macht aber sichtbar, wer das Altsystem überhaupt benutzt.

Welches Modul zuerst umzieht

Nicht jedes Modul kann jederzeit umziehen. Die Rechnungen brauchen die Aufträge, die Aufträge brauchen die Kunden, und das Mahnwesen braucht die Rechnungen. Eine solche harte Abhängigkeit heißt: Ein Modul kann erst im neuen System laufen, wenn seine Voraussetzung dort bereits läuft, oder es zieht in derselben Stufe mit ihr um.

Daraus ergibt sich eine einfache Regel. Zuerst ziehen Randmodule um, auf die sich kein anderes Modul stützt, im Beispiel etwa Versand und Angebote. Ein früher Umzug an einer Stelle mit wenig Verkehr zeigt, ob Weiche, Datenabgleich und Betrieb funktionieren, bevor ein Modul an der Reihe ist, von dem der Umsatz abhängt.

Schwieriger sind Module, die sich gegenseitig brauchen oder deren Voraussetzung selbst lange warten muss. Dann entstehen gekoppelte Umzüge, bei denen zwei Module in derselben Stufe wechseln. Eine gekoppelte Stufe ist ein kleiner Stichtag innerhalb der schrittweisen Ablösung, und sie verdient die gründlichste Vorbereitung.

Den Stufenplan selbst durchrechnen

Der Rechner setzt diese Regeln um. Er nimmt eine Liste fachlicher Module, verteilt einen einstellbaren Anteil harter Abhängigkeiten und plant daraus Stufen, in denen höchstens so viele Module umziehen wie eingestellt. Schalten Sie zwischen Stichtag und schrittweise um und beobachten Sie, in welcher Stufe das Modul Rechnungen wechselt und ob die Stufe gestrichelt als Risiko markiert ist.

Mit den Beispielwerten der Voreinstellung, zehn Modulen, zwei Modulen je Stufe und drei harten Abhängigkeiten, entstehen fünf Stufen. Die Rechnungen ziehen erst in Stufe 4 um, gekoppelt an die Aufträge, die ihrerseits auf die Kunden warten. Als Stichtag gerechnet wechseln alle zehn Module in einer Stufe, und alle drei Abhängigkeiten werden zu gekoppelten Umzügen. Mit nur einem Modul je Stufe verschwindet das Risiko ganz, dafür wächst der Plan auf zehn Stufen.

Die Zahlen sind Stufen und keine Wochen. Wie lange eine Stufe dauert, hängt vom Modul, von den Daten und vom Parallelbetrieb ab. Was der Rechner zuverlässig zeigt, ist die Struktur: welche Module warten, wo Kopplungen entstehen und welcher Hebel sie auflöst.

Parallelbetrieb heißt vergleichen

Während ein Modul umzieht, laufen Alt und Neu eine Stufe lang parallel. Das bringt nur dann Sicherheit, wenn beide Ergebnisse verglichen werden. Die Weiche schickt dieselbe Anfrage an beide Systeme, maßgeblich bleibt zunächst das Altsystem, und jede Abweichung landet in einem Protokoll, das jemand liest.

Vor dem Umschalten sollte schriftlich feststehen, wann der Parallelbetrieb endet: etwa wenn über einen vereinbarten Zeitraum keine ungeklärte Abweichung mehr auftritt und alle bekannten Sonderfälle mindestens einmal durchgelaufen sind. Ohne ein solches Kriterium bleibt der Parallelbetrieb aus Vorsicht bestehen, und das Team pflegt zwei Systeme länger als geplant.

Abweichungen sind dabei nicht immer Fehler des neuen Systems. Oft zeigt der Abgleich eine Regel, die im Altsystem nie dokumentiert wurde, etwa eine Rundung oder einen Rabatt, der nur für eine Kundengruppe gilt. Solche Funde gehören in die Beschreibung des neuen Moduls, bevor das alte abgeschaltet wird.

Wem die Daten während der Ablösung gehören

Die heikelste Frage einer schrittweisen Ablösung betrifft die Daten. Solange ein Modul in beiden Systemen existiert, braucht jedes Datenobjekt genau ein führendes System: Kundenstammdaten werden entweder im alten oder im neuen System geändert, nie in beiden. Das andere System erhält eine Kopie, und die Richtung dieser Kopie wechselt erst mit dem Umzug des Moduls.

Praktisch heißt das, früh eine Zuordnungstabelle für Kennungen anzulegen, weil das neue System eigene Nummern vergibt, und festzulegen, wie oft und in welche Richtung abgeglichen wird. Wer an beiden Enden gleichzeitig schreiben lässt, erzeugt Konflikte, die sich später kaum noch auflösen lassen.

Wenn eine Funktion früher gebraucht wird, als ihr Modul umziehen kann

Im Beispiel soll das Kundenportal früh Aufträge übergeben, das Modul Aufträge kann aber erst in Stufe 4 umziehen. Der Stufenplan beantwortet die Frage deshalb nicht allein. Eine Zwischenlösung an der Weiche kann Aufträge aus dem Portal annehmen, prüfen und über den vorhandenen Weg in das Altsystem schreiben, bis das neue Modul bereitsteht.

Eine solche Zwischenlösung ist bewusst Übergangscode. Sie sollte so gebaut sein, dass sie später vor das neue Modul umgehängt oder entfernt werden kann, und sie gehört mit einem Datum für ihre Überprüfung in den Plan. Sonst wird aus der Übergangslösung ein weiteres Altsystem.

Wann der Stichtag doch die bessere Wahl ist

Eine schrittweise Ablösung kostet Weiche, Parallelbetrieb und Datenabgleich. Diese Kosten lohnen sich nicht in jedem Fall. Ein kleines System mit wenigen Nutzern und ohne Anbindungen lässt sich oft sauberer an einem gut vorbereiteten Tag umstellen.

1. Das System ist klein: Wenn alle Module an einem Tag getestet werden können, bringt die Zerlegung wenig.
2. Es gibt keine Stelle für eine Weiche: Eine Anwendung, deren Daten nur über ihre eigene Oberfläche erreichbar sind, lässt sich schwer abschnittsweise umleiten.
3. Das Datenmodell lässt sich nicht teilen: Wenn fast jede Tabelle von fast jedem Modul geschrieben wird, entstehen in jeder Stufe gekoppelte Umzüge.
4. Der Parallelbetrieb ist teurer als das Risiko: Wenn ein Ausfall von einem Tag verkraftbar ist, darf die Vorbereitung schlanker ausfallen.

Auch dann bleibt ein Teil der Methode nützlich. Die Liste der Module und ihrer Abhängigkeiten zeigt, was am Stichtag gemeinsam funktionieren muss, und damit, was vorher gemeinsam getestet werden sollte.

Womit Sie beginnen können

Die ersten Schritte folgen derselben Logik wie der Stufenplan, und sie lassen sich im eigenen Haus beginnen. Zuerst entsteht eine Liste der fachlichen Module mit ihren Nutzern, Datenflüssen und harten Abhängigkeiten, gezählt statt geschätzt. Danach wird jede Verbindung zu anderen Systemen wie ein Vertrag beschrieben: Format, Richtung, Verhalten im Fehlerfall und Zuständigkeit.

Mit dieser Liste lässt sich ein Randmodul als erster Kandidat wählen, und an ihm zeigt sich, ob Weiche, Abgleich und Betrieb tragen. Welche Unterlagen ein neues Modul braucht, bevor ein anderes Team es betreibt, beschreibt der Leitfaden Vom Proof of Concept in den Regelbetrieb. Was beim Betrieb im eigenen Haus zu klären ist, steht unter Eine Anwendung im eigenen Haus betreiben, und woran sich Abkürzungen im Code zeigen, die jeden weiteren Umzug verteuern, unter Technische Schulden erkennen.

Soll ein Dienstleister die Ablösung begleiten, hilft der Leitfaden Prototyp weiterentwickeln lassen bei der Auswahl. Einen Überblick über Softwareentwicklung bei iiterate gibt die Seite Softwareentwicklung.

Diese Zahl ist eine Summe. Sie setzt sich aus fünf Posten zusammen, die unterschiedlich groß sind, unterschiedlich reagieren und sich mit unterschiedlichen Mitteln verkleinern lassen.

Warum eine einzelne Zeitmessung wenig erklärt

Eine Gesamtzeit beantwortet die Frage, ob ein Assistent zu langsam ist. Sie beantwortet nicht, warum, und damit auch nicht, welche Maßnahme hilft. Eine neue Grafikkarte beschleunigt nur einen der Posten, eine schnellere Suche einen anderen, und beide Investitionen können an der eigentlichen Ursache vorbeigehen.

Hilfreicher ist ein Latenzbudget, wie es aus der Planung von Echtzeitsystemen bekannt ist. Man legt eine Ziel-Antwortzeit fest und verteilt sie auf die Posten, die eine Antwort durchläuft. Überschreitet die Summe das Ziel, zeigt das Budget sofort, welcher Posten zu groß ist.

Beim Maschinenbauer aus dem Beispiel hätte ein solches Budget die Diskussion verkürzt. Statt über Grafikkarten zu streiten, hätte das Team gesehen, welcher Posten die Zielzeit überschreitet und ob er sich mit einer Einstellung verkleinern lässt. Diese Zerlegung lässt sich mit Beispielwerten selbst durchrechnen.

Die fünf Posten einer Antwort

Ein Assistent, der aus eigenen Dokumenten antwortet, arbeitet bei jeder Frage dieselbe Kette ab. Wie diese Kette im Einzelnen aufgebaut ist, beschreibt der Wissensbeitrag Retrieval-Augmented Generation. Für die Antwortzeit zählen fünf Abschnitte davon.

Dokumentabruf. Die Suche ermittelt zur Frage passende Textabschnitte aus dem Index. Ihre Dauer hängt von der Größe des Bestands, vom Suchverfahren und davon ab, wie Berechtigungen gefiltert werden.

Nachsortierung. Ein zweites Modell ordnet die gefundenen Kandidaten neu, bevor die besten an das Sprachmodell gehen. Dieser Schritt heißt Reranking, und seine Dauer wächst mit der Zahl der Kandidaten, die er bewerten muss.

Modellantwort. Das Sprachmodell liest Anweisung, Frage und Abschnitte und schreibt dann die Antwort. Das Lesen des Kontexts kostet Zeit, bevor das erste Wort erscheint, und das Schreiben kostet Zeit für jedes weitere.

Prüfschritt. Eine Prüfung gleicht Aussagen mit Belegen ab und kontrolliert Zugriffsrechte und Format. Sie macht Antworten verlässlicher und fügt dafür einen eigenen Posten hinzu.

Netz. Anfrage und Antwort laufen zwischen Browser, Anwendung, Suche und Modell hin und her. Liegt das Modell bei einem externen Anbieter, kommen weitere Wege hinzu, liegt es im eigenen Netz, fallen sie kürzer aus.

Warum die Modellantwort meist der größte Posten ist

Ein Sprachmodell schreibt keine ganzen Sätze auf einmal. Es erzeugt Tokens, also Wortbausteine, eines nach dem anderen, und jedes neue Token baut auf allen vorherigen auf. Die Schreibzeit ist deshalb ungefähr die Zahl der Tokens mal der Zeit je Token.

Die Zeit je Token ist keine feste Eigenschaft eines Modells. Sie hängt von Modellgröße, Hardware und Quantisierung ab und davon, wie viele Anfragen sich die Rechenkapazität gerade teilen. Zwei gleichzeitige Anfragen auf derselben Grafikkarte werden beide langsamer, und bei einem externen Anbieter kann der Wert mit dessen Auslastung schwanken.

Die Zahl der Tokens bestimmen dagegen Sie. Eine Anweisung, die ausführliche Einleitungen, Wiederholungen der Frage und Zusammenfassungen am Ende verlangt, verdoppelt schnell die Antwortlänge, ohne dass die Antwort besser wird.

Das erste Wort und die fertige Antwort sind zwei Zeiten

Viele Oberflächen zeigen die Antwort, während sie entsteht. Für die Nutzer zählt dann vor allem, wann das erste Wort erscheint, und weniger, wann das letzte steht. Bis zum ersten Wort laufen Abruf, Nachsortierung, Netz und das Lesen des Kontexts, erst danach beginnt das sichtbare Schreiben.

Ein Prüfschritt verändert diese Rechnung. Prüft er die fertige Antwort, bevor sie angezeigt wird, kann die Oberfläche nichts vorab zeigen, und die gefühlte Wartezeit entspricht der vollen Summe. Prüft er fortlaufend oder nur ausgewählte Aussagen, bleibt das schrittweise Anzeigen möglich, dafür kann eine bereits sichtbare Aussage nachträglich zurückgezogen werden.

Welche Variante passt, ist eine fachliche Entscheidung. Bei Auskünften, auf die hin jemand eine Maschine freigibt, ist das Warten auf die geprüfte Antwort das kleinere Übel.

Rechnen Sie ein Latenzbudget selbst durch

Die Demonstration addiert die fünf Posten zu einer Summe und trägt sie maßstäblich gegen eine Ziel-Antwortzeit auf. Voreingestellt sind Beispielwerte für einen Assistenten mit zwei Sekunden Ziel, bei denen die Summe knapp darunter liegt. Die Werte sind keine Messungen, sie machen nur die Größenverhältnisse greifbar.

Stellen Sie die Zeit je Token von 9 auf 14 Millisekunden, als würden sich zwei Anfragen eine Grafikkarte teilen. Kürzen Sie danach die Antwortlänge von 180 auf 110 Tokens und beobachten Sie die Ziellinie.

Bei 14 Millisekunden je Token ragt der Balken um 880 Millisekunden über das Ziel. Mit 110 Tokens liegt die Summe bei 1.900 Millisekunden und damit wieder unter dem Ziel, ohne dass sich an Hardware oder Modell etwas geändert hat.

Was die Rechnung zeigt und was sie auslässt

Die Modellantwort dominiert die Summe in fast jeder Einstellung. Entfallen Nachsortierung und Prüfschritt ganz, spart das in der Voreinstellung zusammen 190 Millisekunden, während 70 Tokens weniger bei 9 Millisekunden je Token 630 Millisekunden sparen. Kürzere Antworten sind deshalb oft die erste und günstigste Korrektur.

Die Rechnung hat drei Lücken, die im Betrieb zählen. Sie rechnet mit einem festen Wert je Posten, obwohl echte Zeiten streuen und Nutzer langsame Antworten stärker wahrnehmen als den Durchschnitt. Sie kennt keine Warteschlange, die entsteht, wenn mehr Fragen eintreffen, als gleichzeitig bearbeitet werden können. Und sie trennt nicht zwischen Lesen und Schreiben, obwohl lange übergebene Abschnitte vor allem das erste Wort verzögern.

Für eine belastbare Aussage braucht es deshalb Messungen am eigenen System. Sinnvoll sind Zeitstempel an jeder Übergabe und eine Auswertung, die neben dem Mittelwert auch die langsamsten Anfragen zeigt, etwa über das 95. Perzentil.

Wie die Betriebsart die Posten verschiebt

Wo das Sprachmodell läuft, verändert vor allem zwei Posten. Bei einem externen Anbieter kommen Netzwege und dessen Auslastung hinzu, im eigenen Netz fallen die Wege kürzer aus, dafür teilen sich alle Nutzer die eigene Rechenkapazität. Eine Grafikkarte, die für ein Fachteam schnell genug ist, kann bei gleichzeitigen Fragen einer ganzen Abteilung spürbar langsamer werden.

Die Betriebsarten selbst, also Cloud-Schnittstelle, Hosting in der EU und Betrieb im eigenen Haus, unterscheiden sich in weit mehr als der Antwortzeit. Eine Gegenüberstellung steht auf der Seite KI-Entwicklung, die Abwägung aus Sicht von Daten und Kosten in On-Premise vs. Cloud-LLM. Was für den eigenen Betrieb an Hardware realistisch ist, beschreibt Lokales LLM im Unternehmen, welche offenen Modelle sich lokal betreiben lassen, der Wissensbeitrag Lokale Sprachmodelle.

Für den Maschinenbauer heißt das: Bevor eine größere Grafikkarte gekauft wird, zeigt eine Messung mit gleichzeitigen Fragen, ob die Zeit je Token unter Last steigt. Steigt sie, hilft mehr Rechenkapazität. Bleibt sie stabil, liegt die Ursache in einem anderen Posten, und die neue Karte würde das Problem nicht lösen.

In welcher Reihenfolge Sie eine langsame Antwort beschleunigen

Die Reihenfolge folgt dem Verhältnis von Wirkung zu Aufwand. Die ersten Schritte ändern Konfiguration und Anweisung, erst die letzten kosten Geld.

1. Zeitstempel je Posten setzen und die langsamsten Anfragen getrennt auswerten.
2. Die Antwortlänge begrenzen: eine kurze Form in der Anweisung verlangen, Wiederholungen der Frage und Schlussformeln streichen.
3. Weniger und kürzere Abschnitte übergeben, wenn die Testfragen zeigen, dass die richtigen Stellen auch so ankommen.
4. Die Zahl der Kandidaten für die Nachsortierung prüfen, denn sie wächst oft unbemerkt mit dem Bestand.
5. Den Prüfschritt so legen, dass nichts doppelt geprüft wird, etwa Rechte vor der Suche statt nach der Antwort.
6. Häufige Fragen mit stabilen Antworten zwischenspeichern, sofern sich die Quellen selten ändern.
7. Erst danach über ein kleineres Modell, andere Hardware oder eine andere Betriebsart entscheiden.

Jede dieser Änderungen kann die Qualität der Antworten berühren. Deshalb läuft nach jedem Schritt dieselbe Testmenge, wie in Warum KI-Features in der Praxis scheitern beschrieben.

Wann die Antwortzeit zweitrangig ist

Nicht jede KI-Anwendung wartet auf einen Menschen. Extraktionen aus Dokumenten, nächtliche Auswertungen oder Zusammenfassungen für einen Bericht laufen im Hintergrund, und dort zählt der Durchsatz pro Stunde mehr als die Sekunden je Anfrage.

Umgekehrt gibt es Anwendungen, bei denen ein Budget von zwei Sekunden zu großzügig ist, etwa Sprachdialoge, in denen eine Pause wie eine Störung wirkt. Dort verschiebt sich die Rechnung zu kurzen Antworten, kleineren Modellen und einer Prüfung, die nicht auf die fertige Antwort wartet. Welche Zielzeit angemessen ist, entscheidet der Einsatz, und das Budget macht sichtbar, was diese Zielzeit kostet.

Mit diesem Satz lässt sich nicht arbeiten, weil er keinen Ort nennt. Ein KI-Feature besteht aus mehreren Stufen, und fast jeder Fehler entsteht an genau einer davon. Das Beispiel mit der Pumpe ist erfunden, der Weg zur Ursache ist übertragbar.

Warum „die KI“ keine Fehlerursache ist

Von außen sind bei einem KI-Feature zwei Dinge sichtbar: die Frage und die Antwort. Alles dazwischen wirkt wie eine geschlossene Kiste, und Fehlermeldungen landen deshalb beim Sprachmodell, weil es der einzige Baustein ist, dessen Namen alle kennen. Die naheliegende Reaktion ist ein anderes Modell, eine längere Anweisung oder ein teurerer Tarif.

In einem gebauten System ist die Kiste eine Kette. Dokumente werden eingesammelt, zerlegt, indiziert und bei jeder Frage durchsucht, erst danach formuliert ein Modell, und im besten Fall prüft eine weitere Stufe das Ergebnis, bevor es ausgegeben wird. Zerlegt man die Meldung des Technikers entlang dieser Kette, zeigt sich ein anderes Bild: Das Handbuch lag im Index, der richtige Abschnitt stand in der Trefferliste aber erst auf Rang sechs, und an das Modell gingen nur die ersten vier.

Die Reparatur liegt in diesem Fall in der Suche. Am Sprachmodell müsste niemand etwas ändern, und ein Modellwechsel hätte den Fehler bestenfalls überdeckt.

Die sieben Stufen eines KI-Features und ihre typischen Fehler

Die folgende Einteilung ist auf Fehlersuche ausgerichtet. Wie die Verarbeitung technisch abläuft, von der Zerlegung über Einbettungen bis zur Neuordnung der Treffer, erklärt der Wissensbeitrag Retrieval-Augmented Generation. Für die Fehlersuche zählt bei jeder Stufe nur, was dort schiefgeht und woran Sie es merken.

1. Eingang. Dokumente, Tickets und Datensätze werden eingesammelt, mit Fassung und Leserechten. Typische Fehler sind ein unvollständiger Bestand, veraltete Fassungen und Scans ohne Textebene. Sie merken es daran, dass Antworten eine überholte Fassung zitieren oder bestimmte Aktenbestände nie auftauchen.

2. Aufbereitung. Texte werden in Abschnitte zerlegt, die einzeln gefunden werden können. Zerreißt die Zerlegung eine Tabelle oder trennt eine Überschrift von ihrem Inhalt, findet die Suche Bruchstücke ohne Zusammenhang. Das Symptom sind Antworten, die eine Zahl ohne ihre Einheit oder Bedingung nennen.

3. Index. Die Abschnitte werden durchsuchbar abgelegt, als Stichwortindex, als Vektorindex oder beides. Fehler entstehen, wenn geänderte Dokumente nicht nachgezogen werden oder Berechtigungen beim Import verloren gehen. Dann zitiert der Assistent Dokumente, die gelöscht sind oder die die fragende Person nicht öffnen dürfte.

4. Abruf. Zur Frage sucht das System passende Abschnitte und übergibt eine begrenzte Anzahl an das Modell. Liegt die richtige Stelle zu weit hinten oder verwendet die Frage andere Wörter als das Dokument, kommt sie nie an. Das Symptom ist eine allgemeine, halb richtige Antwort, obwohl das Wissen im Bestand steht.

5. Modell. Das Sprachmodell formuliert aus Frage, Anweisung und übergebenen Abschnitten eine Antwort. Es kann Abschnitte falsch gewichten, Bedingungen weglassen oder Lücken mit plausiblem Allgemeinwissen füllen. Sie erkennen diesen Fall daran, dass die richtige Stelle nachweislich übergeben wurde und die Antwort trotzdem abweicht.

6. Prüfung. Eine Prüfstufe gleicht Aussagen mit Belegen ab, kontrolliert Format und Rechte und hält im Zweifel eine Antwort zurück. Fehlt sie oder ist sie zu großzügig eingestellt, gehen unbelegte Aussagen durch. Ist sie zu streng, bekommen Nutzer auffällig oft gar keine Antwort.

7. Ausgabe. Die Antwort erreicht ein Zielsystem, etwa eine Oberfläche, ein Ticket oder einen Datensatz. Dort gehen Fußnoten verloren, Zahlen werden umformatiert oder Felder abgeschnitten. Das Symptom ist eine Antwort, die im Protokoll richtig war und beim Nutzer falsch ankommt.

Warum die Suche so oft die Ursache ist

Ein Sprachmodell liest bei jeder Frage nur das, was im Kontextfenster liegt, also Anweisung, Frage und übergebene Abschnitte. Das ist vergleichbar mit einem Kollegen, dem man vier Seiten aus einem Ordner in die Hand drückt: Er kann gut formulieren, aber nur über diese vier Seiten. Wie viele Abschnitte übergeben werden, ist eine Einstellung, und jede Einstellung schneidet die Trefferliste an irgendeiner Stelle ab.

Dazu kommt ein Wortproblem. Der Techniker schreibt „Leckrate“, das Handbuch spricht von „Leckage“, und eine reine Stichwortsuche sieht darin zwei verschiedene Begriffe. Vektorsuche und hybride Verfahren mildern das, besonders bei Fachbegriffen, Typenbezeichnungen und zusammengesetzten Wörtern bleibt die Lücke aber ein häufiger Grund für Fehltreffer. Welche Verfahren es gibt und wie sie sich kombinieren lassen, beschreibt der Wissensbeitrag Semantische Suche im Unternehmen.

Beide Effekte sind leise. Die Antwort klingt flüssig, weil das Modell aus den übergebenen Abschnitten etwas Passendes macht, und niemand sieht die Trefferliste, in der die richtige Stelle knapp unter der Grenze steht.

Probieren Sie die Suche aus Stufe 4 selbst aus

Die Demonstration arbeitet mit dreizehn erfundenen Abschnitten aus Wartungshandbuch, Norm-Auszug, Datenblatt und Instandhaltungsprotokollen. Voreingestellt ist die Frage des Technikers, bewertet wird mit einer einfachen Stichwortsuche, die seltene Wörter stärker gewichtet. Achten Sie auf die markierte Zeile mit dem Handbuchabschnitt 4.5 Leckage und auf die Angabe, ob er beim Modell ankommt.

Stellen Sie danach sechs Abschnitte im Kontextfenster ein. Schalten Sie anschließend zurück auf vier und aktivieren Sie die Synonymliste.

Mit sechs Abschnitten rutscht der Handbuchabschnitt gerade noch ins Kontextfenster. Mit der Synonymliste steigt er auf Rang 1, weil die Suche „Leckrate“ nun auch als „Leckage“ versteht. Beide Korrekturen liegen in Stufe 4, und keine davon berührt das Sprachmodell.

Was die Demonstration zeigt und wo sie aufhört

Die zwei Korrekturen haben unterschiedliche Preise. Mehr Abschnitte im Kontextfenster verlängern jede Anfrage und geben dem Modell mehr Material, das es falsch gewichten kann. Eine Synonymliste wirkt gezielt, muss aber von jemandem gepflegt werden, der die Sprache der Dokumente und die Sprache der Fragenden kennt.

Probieren Sie auch die Frage „Wann ist die Pumpe undicht?“. Ohne Synonymliste landet der richtige Abschnitt auf Rang 5, mit ihr auf Rang 1, und direkt dahinter steht der Norm-Auszug mit seiner Definition von Dichtheit. Das ist ein gutes Ergebnis, weil beide Stellen zusammen die vollständige Antwort ergeben.

Die Demonstration hat bewusst enge Grenzen. Sie rechnet ohne Einbettungen, ohne Neuordnung und ohne Sprachmodell, und ihr Bestand ist so klein, dass sich jede Zeile nachvollziehen lässt. Die Rangzahlen sind Rechenergebnisse der Demonstration und keine Messwerte aus einem System, das Muster dahinter gilt aber auch in großen Beständen: Eine richtige Antwort setzt voraus, dass die richtige Stelle ankommt.

Eine Testmenge macht Fehler zählbar

Einzelne Meldungen zeigen, dass etwas schiefgeht, aber nicht, wie oft. Dafür braucht es eine feste Sammlung echter Fragen, zu denen vorher notiert ist, welche Fundstelle eine richtige Antwort zitieren müsste. Einige Dutzend solcher Fragen aus dem Alltag genügen für einen ersten Stand.

Die Testmenge trennt zwei Fragen, die in einer Fehlermeldung vermischt sind. Die erste lautet, ob die richtige Fundstelle im Kontextfenster angekommen ist; wenn nicht, liegt der Fehler in den Stufen 1 bis 4. Die zweite lautet, ob die Antwort aus der angekommenen Stelle richtig und belegt formuliert ist; wenn nicht, liegt er in Modell, Anweisung oder Prüfung.

Nach jeder Änderung an Zerlegung, Index, Suche, Modell oder Anweisung läuft dieselbe Testmenge erneut. So wird sichtbar, ob eine Änderung geholfen oder an anderer Stelle etwas verschlechtert hat. Wie sich Antworten an Quellen binden und bewerten lassen, bis hin zu menschlichen Stichproben, behandelt der Wissensbeitrag KI-Antworten prüfen. Warum diese Auswertung eine laufende Position ist und keine Projektphase, steht in Was ein RAG-System im Betrieb wirklich kostet.

In welcher Reihenfolge Sie eine Fehlermeldung eingrenzen

Für eine einzelne Meldung lohnt eine feste Reihenfolge, weil jeder Schritt ganze Stufen ausschließt. Wer beim Modell beginnt, prüft zuerst die Stelle, an der der Fehler am seltensten sichtbar wird.

1. Frage und erwartete Fundstelle festhalten. Ohne die Stelle, die eine richtige Antwort zitieren müsste, lässt sich kein Fehler belegen.
2. Prüfen, ob die Fundstelle im Index liegt, in der gültigen Fassung und mit den richtigen Rechten. Fehlt sie, liegt die Ursache in Stufe 1 bis 3.
3. Den Rang der Fundstelle in der Trefferliste ansehen. Liegt sie hinter der Grenze des Kontextfensters, liegt die Ursache in Stufe 4.
4. Wurde die Stelle übergeben, Anweisung und Antwort vergleichen. Weicht die Antwort trotzdem ab, liegt die Ursache in Stufe 5.
5. Zuletzt Prüfstufe und Ausgabe kontrollieren, also ob eine belegte Antwort zurückgehalten, gekürzt oder umformatiert wurde.

Dafür braucht das System ein Suchprotokoll, das zu jeder Antwort festhält, was gefunden, was übergeben und was verwendet wurde. Fehlt dieses Protokoll, bleibt nur Raten, und die Fehlersuche endet wieder beim Modell.

Wann ein KI-Feature nicht die passende Lösung ist

Nicht jede Frage aus dem Betrieb braucht sieben Stufen. Lässt sich eine Frage als feste Abfrage formulieren, etwa nach einem Termin oder einem Stammdatum, ist eine Datenbank genauer und günstiger als jedes Sprachmodell.

Zwei weitere Fälle scheitern vor der Technik. Kursieren drei Fassungen desselben Handbuchs, muss zuerst festgelegt werden, welche gilt. Und ohne eine Person, die neue Fassungen einpflegt und alte zurückzieht, veralten die Antworten, ohne dass es jemand bemerkt.

Löst ein einzelner Fehler Zahlungen, Sicherheitsrisiken oder Stillstand aus, gehört ein Mensch an die Entscheidung. Ob die Pumpe P-40 wieder anläuft, entscheidet der Techniker, und der Assistent liefert ihm die Fundstelle dazu. Wie weit Ihr eigener Bestand für ein solches System vorbereitet ist, lässt sich mit dem RAG-Readiness-Check einschätzen, welche Bausteine eine Umsetzung umfasst, beschreibt die Seite KI-Entwicklung.

Die Frage klingt nach einem Fall für Augmented Reality. Häufig genügt aber eine Rechnung, weil Einhausung und Raum ohnehin als Maße vorliegen. Wo diese Rechnung aufhört, wie fein ein 3D-Modell für die räumliche Ansicht sein muss und wann AR tatsächlich hilft, lässt sich klar trennen.

Warum die Frage nach dem Raum zwei Fragen sind

Wer fragt, ob eine Einhausung in die Halle passt, meint meistens zwei Dinge. Die erste Frage ist, ob sie mit genügend Abstand zu Wänden und Decke aufgestellt werden kann, damit Wartung und Bedienung möglich bleiben. Die zweite ist, ob die Maschine, die darin stehen soll, durch die Hallentür kommt.

Beide Fragen haben eigene Engstellen. Eine Einhausung kann bequem im Raum stehen, während die Maschine an der Türbreite scheitert, und umgekehrt. Ein Raumcheck, der nur eine der beiden Fragen beantwortet, erzeugt deshalb falsche Sicherheit.

Die Maße der Einhausung kommen im besten Fall aus einem Konfigurator, in dem der Kunde Breite, Tiefe, Höhe und Türen einstellt. Wie ein solcher Konfigurator Zeichnung, Stückliste und Gewicht aus derselben Regel ableitet, zeigt die Seite 3D-Konfiguratoren.

Was eine Raumprüfung rechnen muss

Für die Aufstellung braucht die Einhausung ihre eigene Grundfläche plus einen Wartungsabstand an jeder Seite. Vor Türen der Einhausung kommt ein Schwenkbereich hinzu, der größer sein kann als der Wartungsabstand, und in der Höhe muss Luft bis zur Decke bleiben. Welcher Abstand für eine bestimmte Maschine nötig ist, steht in deren Unterlagen, die Rechnung übernimmt ihn nur als Eingabe.

Der Schwenkbereich wird in Skizzen leicht vergessen. Eine Einhausung, die mit Wartungsabstand gerade in den Raum passt, kann trotzdem unbrauchbar sein, wenn sich ihre Tür nicht vollständig öffnen lässt. Die Rechnung setzt deshalb vor jeder Tür den größeren der beiden Werte an.

Für die Einbringung zählt der Querschnitt der Maschine. Aufrecht muss ihre schmalere Grundseite durch die Türbreite und ihre Höhe durch die Türhöhe passen. Darf die Maschine gekippt werden, kommen weitere Lagen hinzu, und die Rechnung nimmt die günstigste davon.

Aus beiden Prüfungen entstehen vier Angaben, die ein Kunde versteht: ob die Einhausung passt, ob die Maschine hineinkommt, wie viel freie Fläche bleibt und wo der engste Abstand liegt. Mehr braucht es für eine erste Antwort selten.

Prüfen Sie die Einhausung selbst

Die Demonstration rechnet beide Prüfungen für eine Einhausung von vier mal drei Metern und 2.200 Millimetern Höhe mit einer Tür. Voreingestellt ist eine Halle von 6.500 mal 4.600 Millimetern mit 800 Millimetern Wartungsabstand, alles Beispielwerte. In dieser Einstellung fehlen 200 Millimeter Tiefe, und die Draufsicht markiert die betroffenen Wände.

Senken Sie den Wartungsabstand auf 600 Millimeter, oder nehmen Sie der Einhausung einen Meter Tiefe. Stellen Sie danach die Türbreite auf 1.500 Millimeter und erlauben Sie das Kippen.

Mit 600 Millimetern Wartungsabstand passt die Einhausung, und es bleiben knapp sechs Quadratmeter frei. Bei 1.500 Millimetern Türbreite kommt die Maschine aufrecht nicht hinein, gekippt meldet die Rechnung „ja“ mit 0 Millimetern Luft.

Was die Prüfung zeigt und was sie verschweigt

Das Ergebnis mit 0 Millimetern Luft ist rechnerisch richtig und praktisch wertlos. Keine Maschine lässt sich ohne Spiel durch eine Öffnung bewegen, und Stapler, Transportrollen oder Anschlagmittel brauchen zusätzlichen Platz. Eine brauchbare Prüfung rechnet deshalb mit einer Mindestluft, die der Hersteller aus seiner Erfahrung festlegt.

Auch die Aufstellung ist vereinfacht. Die Rechnung setzt die Einhausung mittig, kennt keine Stützen, Kabeltrassen, Kranbahnen oder Bodenabläufe und fragt nicht nach der Tragfähigkeit des Bodens. Sie prüft außerdem nur die letzte Tür, obwohl der Transportweg über Flure, Rampen oder einen Aufzug oft enger ist.

Als erste Antwort taugt sie trotzdem. Sie ersetzt eine Rückfrage durch eine Zahl und zeigt, welche Angabe fehlt, bevor jemand zum Aufmaß fährt.

Welche Angaben ein Kunde liefern sollte

Die Qualität eines Raumchecks hängt an den Eingaben. Fünf Angaben decken die meisten Fälle ab, und viele Kunden können sie ohne Ortstermin liefern.

1. Raummaße: lichte Breite, Tiefe und Höhe am Aufstellort, gemessen unter der niedrigsten Stelle wie Trägern oder Leitungen.
2. Tür- und Tormaße: lichte Breite und Höhe jeder Öffnung auf dem Transportweg, auch der ersten.
3. Hindernisse: Stützen, Kabeltrassen, Kranbahnen und Bodenabläufe mit ihrer ungefähren Lage.
4. Zugang: von welcher Seite die Einhausung bedient und gewartet wird.
5. Transport: ob die Maschine gekippt werden darf und womit sie bewegt wird.

Liegen diese Angaben vor, lässt sich die Prüfung automatisch rechnen und als Teil der Anfrage mitschicken. Der Innendienst sieht dann neben der gewählten Einhausung auch, ob sie beim Kunden steht und hineinkommt.

Wie fein das Modell für die räumliche Ansicht sein muss

Soll der Kunde die Einhausung zusätzlich in 3D drehen oder später im eigenen Raum sehen, braucht jedes Teil eine Oberfläche aus Dreiecken. Ein Modell direkt aus der Konstruktion ist dafür fast immer zu fein, weil es Details trägt, die aus Betrachtungsabstand niemand sieht.

Die Zahl der Dreiecke lässt sich aus der Stückliste abschätzen: Stückzahl je Position mal Dreiecke je Teil, summiert über alle Positionen. Für die Einhausung aus der Demonstration ergibt das in einer schlichten Vertriebsansicht rund 800 Dreiecke, in einer konstruktionsnahen Fassung mit abgerundeten Profilen knapp 7.000 und in einer fertigungsnahen Fassung mit Verbindern und Fußplatten über 32.000.

Die fertigungsnahe Fassung hat damit rund 42-mal so viele Dreiecke wie die Vertriebsansicht, und für die Frage nach dem Raum zeigt sie nichts Zusätzliches. Welcher Detailgrad trägt, entscheidet der Zweck: Für Maß und Aufstellung genügt die schlichte Fassung, für eine Erklärung der Verbindungstechnik lohnt die feinere. Wie sich die Budgets eines Modells im Browser rechnen lassen, zeigt Wie groß darf ein 3D-Modell im Browser sein?.

Die vereinfachte Fassung sollte nicht von Hand entstehen. Wird sie bei jeder Konstruktionsänderung automatisch aus dem Modell abgeleitet, stimmen Maße und Stückzahlen weiter mit der Konstruktion überein. Ein nachgebautes Vertriebsmodell zeigt dagegen nach der ersten Änderung eine Einhausung, die es so nicht mehr gibt.

Wann AR die Frage besser beantwortet als eine Rechnung

Eine Rechnung braucht Maße, und manche Räume lassen sich schlecht in Maße fassen. Unregelmäßige Grundrisse, verstreute Hindernisse oder eine Halle voller Bestandsanlagen sind mit fünf Zahlen nicht beschrieben. Dann kann eine AR-Ansicht helfen, die das Modell über die Kamera eines Telefons oder Tablets maßstäblich in den realen Raum stellt.

Der Vorteil liegt im Blick vor Ort. Der Kunde sieht, ob die Einhausung vor einer Stütze endet oder eine Kabeltrasse berührt, und das Gespräch mit dem Hersteller beginnt mit einem gemeinsamen Bild. Für diesen Zweck genügt das leichte Modell der Vertriebsansicht.

AR hat eigene Grenzen. Die Lageerkennung braucht Kanten und Muster in der Umgebung, und gleichförmige Flächen, Glas oder schwaches Licht bieten davon wenig, was in Werkhallen häufig vorkommt. Die Anwendung muss zudem auf den Geräten der Kunden laufen, und der Zugriff auf die Kamera muss vorher freigegeben werden.

Die Reihenfolge ergibt sich daraus fast von selbst. Zuerst kommen Regel und Maße, dann die Rechnung, und AR dort, wo Maße den Raum nicht beschreiben.

Wann sich Raumcheck und 3D nicht lohnen

Gibt es nur wenige Ausführungen und stellt kaum ein Kunde die Frage nach dem Raum, ist eine Maßzeichnung mit Mindestabständen die günstigere Antwort. Sie lässt sich drucken, in ein Angebot legen und braucht keine Pflege.

Steht die Regel für Abstände und Varianten nur in einem Kopf, kommt die Software zu früh. Der erste Schritt ist dann, Grenzen und Abhängigkeiten aufzuschreiben, damit Konfigurator, Stückliste und Prüfung dieselbe Quelle lesen, wie Vom Grasshopper-Modell zum Web-Konfigurator beschreibt.

Und endet die Anfrage samt Raumcheck im Postfach, weil jemand sie von Hand ins ERP-System übertragen muss, verschiebt sich der Aufwand nur an eine andere Stelle. Ob sich ein parametrisches Modell für Ihr Produkt rechnet, lässt sich mit den Kriterien aus Wann sich ein parametrisches Modell rechnet abschätzen.

Wer diese drei Fälle ausschließen kann, hat eine gute Ausgangslage. Dann lohnt es, mit der Regel und dem Raumcheck zu beginnen und 3D-Modell und AR-Ansicht erst folgen zu lassen, wenn die Anfragen zeigen, dass Kunden den Raum auch sehen wollen.

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

Quels types de financement existent

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

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

Les programmes fédéraux en bref

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

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

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

Les financements au niveau européen

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

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

Les programmes régionaux en Rhénanie-Palatinat

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

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

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

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

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

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

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

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

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

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

Étape par étape jusqu'à la demande

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

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

Erreurs typiques

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

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

Quel programme pour quel projet d'IA

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

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

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

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

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

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

Ce qu'est Slush

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

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

Ce qu'apporte iiterate

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

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

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

Qui devrait nous rencontrer

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

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

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

Convenir d'un rendez-vous à Helsinki

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

La spécification, sans le marketing

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Les spécifications qui portent une décision

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

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

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

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

Le prix : une seule ligne a changé

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

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

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

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

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

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

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

Changements cassants par rapport à Fable 5 :

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

Ajouts :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ce que cela signifie pour une décision en Allemagne

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

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

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

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

Le tableau que presque tout le monde publie est faussé

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

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

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

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

Ce qui se compare vraiment à l'identique

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

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

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

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

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

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

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

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

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

Ce qui ne se compare pas, et pourquoi

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

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

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

Les classements tiers se contredisent ouvertement

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ce que cela signifie pour une décision en Allemagne

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

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

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

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

Die Ursache ist fast immer die Datenstruktur: die Bäume, mit denen parametrische Umgebungen Listen von Listen verwalten. Etwa alle Fenster je Geschoss je Fassade. Wer diese Ebenen einmal falsch zusammenführt, bekommt kein Fehlerbild, sondern ein anderes Bauwerk.

Warum der Fehler nicht auffällt

Weil die Ausgabe plausibel ist. Wenn 120 Paneele erwartet werden und 120 Paneele entstehen, ist die erste Prüfung bestanden. Dass Paneel 47 die Maße von Position 74 trägt, sieht man an einer Fassade mit ähnlichen Elementen nicht.

Verstärkt wird das dadurch, dass parametrische Umgebungen selten hart abbrechen. Sie gleichen Listen unterschiedlicher Länge stillschweigend an, indem sie den letzten Wert wiederholen. Das ist im Alltag bequem und in genau diesem Fall fatal: die Struktur bleibt heil, der Inhalt nicht.

Die drei Muster, die fast alle Fälle erklären

Erstens der Ebenenversatz. Zwei Datenströme werden zusammengeführt, die auf unterschiedlichen Ebenen verzweigt sind. Einer trägt die Struktur Fassade zu Geschoss zu Öffnung, der andere nur Fassade zu Öffnung. Das Ergebnis hat die richtige Anzahl und die falsche Zuordnung.

Zweitens das ungewollte Abflachen. Ein Arbeitsschritt, der die Baumstruktur einebnet, um eine Operation zu ermöglichen, und danach wird nie wieder verzweigt. Ab dieser Stelle weiß das Modell nicht mehr, welches Element zu welchem Geschoss gehört, und es sagt es nicht.

Drittens die Wiederholung des letzten Werts. Eine Liste mit 12 Werten trifft auf eine mit 120 Elementen. Die ersten 12 stimmen, die restlichen 108 tragen den zwölften Wert. Der Fehler ist am Anfang der Liste unsichtbar und am Ende systematisch.

Prüfen statt hinsehen

Die wirksamste Gegenmaßnahme ist keine höhere Aufmerksamkeit, sondern eine Zählung. An jeder Stelle, an der zwei Ströme zusammenkommen, gehört die erwartete Zahl der Zweige und die erwartete Zahl der Elemente je Zweig ausgeschrieben und mit der tatsächlichen verglichen.

Das kostet ein paar Minuten pro Zusammenführung und fängt alle drei Muster oben ab, weil alle drei die Zählung verändern, bevor sie die Geometrie verändern.

Zweite Maßnahme: eine sichtbare Probe. Ein Element wird eingefärbt oder beschriftet und im Modell verfolgt, vom Eingang bis zum Zuschnitt. Wenn Position 47 am Ende noch Position 47 ist, stimmt die Zuordnung. Das ist der einzige Test, der die ganze Kette abdeckt.

Dritte Maßnahme: die Struktur benennen. Wer die erwartete Baumstruktur an den wichtigen Stellen als Kommentar hinschreibt, dokumentiert nicht nur, sondern zwingt sich zu der Frage, ob sie noch stimmt.

Warum das teurer ist als es klingt

Weil der Fehler nach unten durchschlägt. Aus derselben Struktur entstehen Zuschnitte, Stücklisten und Preise. Eine Zuordnung, die im Bild nicht auffällt, fällt in der Fertigung auf, wenn das Material bereits geschnitten ist.

Und weil das Vertrauen mitgeht. Ein Team, das einmal erlebt hat, dass ein parametrisches Modell überzeugend falsch war, prüft danach jede Ausgabe von Hand nach. Damit ist der Zeitgewinn weg, der der Grund für die Methode war.

Was wir uns angewöhnt haben

Zählprüfungen an jeder Zusammenführung, eine markierte Probe je Bauteilfamilie, und Cluster mit festgelegten Ein- und Ausgängen statt gewachsener Graphen. Ein Cluster erzwingt eine Entscheidung darüber, welche Struktur hinein- und herausgeht, und genau diese Entscheidung ist es, die sonst unterbleibt.

Nichts davon ist aufwendig. Es ist die Sorte Disziplin, die aus der Softwareentwicklung kommt und in parametrischen Modellen aus demselben Grund wirkt: der Fehler, der nicht abbricht, ist der teuerste.

Das ist der Punkt, an dem aus Computational Design Softwareentwicklung wird. Eine Definition lässt sich ohne Oberfläche auf einem Server betreiben und über eine Schnittstelle ansprechen. Was dann davorsteht, kann ein Konfigurator im Browser sein, eine Angebotsrechnung, eine Prüfung in einem bestehenden System oder alles drei aus derselben Quelle.

Was ein Geometrie-Server tatsächlich ist

Ein Rechenknoten, der die Definition geladen hat, Parameter entgegennimmt und das Ergebnis zurückgibt: Geometrie in einem Austauschformat, dazu die Kennzahlen, die im Modell ohnehin berechnet werden. Fläche, Gewicht, Teilezahl, Verschnitt, Materialbedarf.

Der entscheidende Teil ist der zweite. Ein Konfigurator, der nur ein Bild liefert, ist eine Visualisierung. Einer, der zusätzlich die Stückliste und den Materialbedarf zurückgibt, ist ein Vertriebswerkzeug, und das ist der Unterschied, der ein solches Vorhaben trägt.

Die Definition bleibt dabei dieselbe Datei, mit der entworfen wird. Genau das ist der Punkt: es gibt keine zweite Nachbildung der Logik, die auseinanderlaufen kann.

Warum die zweite Nachbildung das eigentliche Problem ist

Der übliche Weg zu einem Konfigurator führt über eine Neuimplementierung: Ein Entwicklungsteam bekommt die Regeln als Dokument beschrieben und baut sie in der Anwendung nach. Von diesem Tag an gibt es zwei Wahrheiten.

Sie laufen auseinander, und zwar leise. Der Entwurf bekommt eine neue Randbedingung, der Konfigurator nicht. Ein halbes Jahr später verkauft der Vertrieb eine Ausführung, die die Fertigung ablehnt, und niemand kann sagen, seit wann.

Mit der Definition als Dienst gibt es diese Klasse von Fehlern nicht. Eine Regeländerung im Entwurf ist eine Regeländerung im Verkauf, weil es dieselbe Regel ist.

Der Zuschnitt, der in der Praxis funktioniert

Nicht jede Anfrage darf eine volle Berechnung auslösen. Bewährt hat sich eine Trennung in drei Stufen: eine sofortige Vorschau aus vorberechneten Zwischenständen, eine vollständige Berechnung auf Anforderung, und eine Ableitung der Fertigungsdaten erst nach der Auswahl.

Der Variantenraum wird dafür vorher abgetastet und die Ergebnisse werden abgelegt. Was ein Kunde im Browser bewegt, ist dann meistens eine Auswahl aus bekannten Ergebnissen und keine Live-Rechnung. Das ist der Unterschied zwischen einer Antwort in Millisekunden und einer in zwanzig Sekunden.

Für die Darstellung im Browser wird die Geometrie vereinfacht ausgeliefert. Wichtig ist, dass diese Vereinfachung automatisiert aus dem Konstruktionsmodell fällt und nicht von Hand gepflegt wird, sonst ist die zweite Wahrheit über die Hintertür wieder da.

Woran es tatsächlich klemmt

Rechenzeit. Eine Definition, die im Entwurf zwanzig Sekunden braucht, braucht sie auch auf dem Server. Interaktiv ist das nicht. Entweder wird die Definition auf Geschwindigkeit hin überarbeitet, was oft möglich und selten beliebt ist, oder der Variantenraum wird vorberechnet.

Zustand. Entwurfsumgebungen halten Zustand zwischen Aufrufen. Ein Dienst, der viele Anfragen parallel bedient, darf das nicht. Definitionen, die sich auf zuletzt geladene Dateien oder Referenzobjekte verlassen, verhalten sich unter Last nicht reproduzierbar, und dieser Fehler tritt genau dann auf, wenn niemand zusieht.

Lizenzierung. Der Serverbetrieb einer Entwurfsumgebung ist lizenzrechtlich eine andere Frage als der Arbeitsplatzbetrieb. Das gehört vor die Architekturentscheidung und nicht danach, weil es das gesamte Betriebsmodell bestimmt.

Und Fehlerfälle. Eine unzulässige Parameterkombination darf keinen Serverfehler erzeugen, sondern muss eine begründete Ablehnung zurückgeben. Randbedingungen als Prüfungen im Modell zahlen sich hier ein zweites Mal aus.

Wo die Daten bleiben

Der gesamte Aufbau lässt sich im eigenen Haus betreiben. Das ist kein Randthema: eine Definition enthält die Konstruktionslogik eines Produkts, und für viele Hersteller ist genau das der Kern dessen, was nicht abfließen darf.

Wir bauen solche Dienste deshalb so, dass Rechenknoten, Ergebnisspeicher und Auslieferung in der Infrastruktur des Kunden stehen können, mit einer Schnittstelle als einziger Berührungsfläche nach außen.

Wann sich der Schritt lohnt

Wenn dieselben Fragen mehrfach im Monat an dieselbe Person gehen. Wenn der Vertrieb Varianten verkaufen soll, die er selbst nicht durchrechnen kann. Wenn aus der Geometrie ohnehin Stücklisten oder Preise entstehen sollen.

Und nicht, wenn der Konfigurator vor allem hübsch sein soll. Ein 3D-Konfigurator ohne Kennzahlen dahinter ist eine Visualisierung mit Wartungsaufwand, und die gibt es billiger.

Die ehrliche Antwort ist eine Rechnung, keine Haltung. Ein parametrisches Modell verschiebt Aufwand von hinten nach vorne. Es kostet mehr, bevor die erste Ausführung steht, und weniger bei jeder weiteren. Ob sich das trägt, hängt an drei Größen, die sich vor Projektbeginn abschätzen lassen.

Die drei Größen, an denen es hängt

Die erste ist die Zahl der Ausführungen. Nicht die Zahl der Varianten, die im Entwurf betrachtet werden, sondern die Zahl der Teile, Module oder Objekte, die am Ende wirklich hergestellt oder gebaut werden. Zwanzig unterschiedliche Fassadenpaneele sind ein Fall dafür. Ein Bauwerk ist es nicht.

Die zweite ist die Zahl der Änderungsrunden. Sie wird fast immer unterschätzt und ist der eigentliche Hebel. Ein Entwurf, der viermal überarbeitet wird, wird bei manueller Bearbeitung viermal vollständig nachgezogen. Ein Regelwerk wird einmal angepasst und rechnet neu.

Die dritte ist die Kopplung zwischen Entwurf und Nachgelagertem. Wenn aus derselben Geometrie auch Stücklisten, Zuschnitte, Angebotspreise oder ein Konfigurator entstehen sollen, entsteht der Nutzen nicht einmal, sondern pro angeschlossenem Schritt.

Eine Faustregel, die trägt

Als grobe Orientierung aus umgesetzten Projekten: Der Aufbau einer belastbaren Definition kostet ungefähr das Drei- bis Fünffache der ersten manuell gezeichneten Variante. Jede weitere Variante kostet danach nahezu nichts.

Daraus folgt der Umschlagpunkt bei etwa fünf Ausführungen, wenn sich nichts mehr ändert. Er verschiebt sich auf zwei bis drei, sobald mit mindestens einer echten Änderungsrunde zu rechnen ist, weil die Änderung im Regelwerk einmal und in der Zeichnung pro Variante anfällt.

Diese Zahlen sind Größenordnungen und keine Kalkulation. Sie sind trotzdem nützlich, weil sie die Diskussion an der richtigen Stelle führen: nicht darüber, ob Parametrik beeindruckend ist, sondern darüber, wie oft sich Ihr Entwurf ändern wird.

Wo die Rechnung kippt, und das wird selten gesagt

Bei einem einmaligen Entwurf ohne Wiederholung. Ein Sonderbauteil, ein Messestand, ein Objekt, das genau einmal existiert: hier gewinnt Zeichnen, und zwar deutlich. Ein Regelwerk für eine einzige Ausführung ist ein teurer Umweg.

Bei unklaren Randbedingungen. Parametrik zwingt dazu, die Regel vorher zu formulieren. Wenn niemand sagen kann, welche Maße gelten, welche Toleranzen zulässig sind und welche Ausführungen ausgeschlossen sind, entsteht ein Modell, das schnell viele falsche Varianten erzeugt. Das ist schlechter als eine Zeichnung, weil es überzeugender aussieht.

Bei Entwürfen, deren Wert in der Ausnahme liegt. Ein Regelwerk ist gut in dem, was sich wiederholt. Wo die gestalterische Qualität gerade aus dem Bruch mit der Regel entsteht, arbeitet die Methode gegen das Ziel, und die Ausnahmen zurück ins Modell zu bauen kostet mehr als sie erspart.

Und bei Teams ohne Übernahme. Eine Definition, die nur ihr Autor ändern kann, ist eine Abhängigkeit und kein Werkzeug. Wenn niemand im Haus sie weiterführen soll oder kann, gehört das in die Rechnung.

Was die Rechnung deutlich verbessert

Bauteilfamilien statt Einzelteile. Fünf Familien mit je zwanzig Maßen sind herstellbar und kalkulierbar, hundert Unikate sind es meist nicht. Die Familienbildung ist der Schritt, in dem ein parametrisches Modell den Preis wirklich senkt, und sie ist eine Entwurfsentscheidung, keine Software-Einstellung.

Randbedingungen als Prüfungen im Modell. Wenn eine unzulässige Ausführung gar nicht erst entsteht, entfällt die Prüfschleife am Ende. Das ist derselbe Gedanke wie ein Test in der Softwareentwicklung und wirkt aus demselben Grund.

Und eine Definition, die wie Software behandelt wird: benannt, strukturiert, kommentiert, versioniert. Eine gewachsene Definition ohne Struktur ist nach sechs Monaten für niemanden mehr änderbar, auch nicht für ihren Autor. Dann ist der eingesparte Aufwand zurück.

Wie wir das vor einem Angebot klären

Wir fragen nach der Zahl der herzustellenden Ausführungen, nach der erwarteten Zahl der Abstimmungsrunden und danach, was aus der Geometrie außer Bildern noch entstehen soll. Diese drei Antworten reichen in den meisten Fällen für eine belastbare Einschätzung.

Fällt sie negativ aus, sagen wir das. Ein Vorhaben, dem wir vom parametrischen Weg abraten, ist ein besseres Ergebnis als eine Definition, die niemand braucht.

Was hier steht, sind keine Preise. Es sind die Kostenstellen, nach denen Sie ein Angebot durchsuchen sollten, und die Größenordnungen, in denen sie zueinander stehen.

Die Inferenz ist selten das Problem

Die Rechnung, mit der gerechnet wird, ist die pro Anfrage: Kontext hinein, Antwort heraus, Preis je Token. Sie ist gut kalkulierbar und in den meisten Häusern kleiner als erwartet, weil die Zahl der Anfragen kleiner ist als erwartet. Ein internes Wissenssystem mit 200 Beschäftigten sieht keine Millionen Anfragen.

Worauf zu achten ist: deutschsprachige Texte verbrauchen spürbar mehr Token als englische, und ein großzügig gefülltes Kontextfenster kostet pro Anfrage mehr als eine gute Suche davor. Wer Retrieval und Reranking ernst nimmt, senkt damit auch die laufenden Kosten, nicht nur die Fehlerquote.

Der Index ist die eigentliche laufende Position

Ein Index ist kein Bauwerk, das fertig wird. Neue Dokumente müssen hinein, geänderte ersetzt, gelöschte entfernt. Das ist Betrieb, und es braucht jemanden, der zuständig ist.

Der teure Sonderfall ist der Wechsel des Embedding-Modells. Embeddings sind nur untereinander vergleichbar, also erzwingt jeder Wechsel die Neuberechnung des gesamten Bestands. Bei einigen zehntausend Dokumenten ist das ein Wochenendlauf, bei Millionen eine Planung. Wer das nicht einkalkuliert, sitzt auf dem Modell fest, mit dem er angefangen hat.

Dazu kommt die Pflege des Bestands selbst, und das ist die Position, die am häufigsten fehlt. Ein Retrieval-System zitiert eine überholte Arbeitsanweisung genauso überzeugend wie die gültige. Aussortieren ist Handarbeit und wird wichtiger, nicht unwichtiger, sobald das System benutzt wird.

Evaluation ist eine Kostenstelle, keine Phase

Der Goldstandard-Testsatz aus echten Fragen mit geprüften Antworten entsteht einmal und veraltet danach. Neue Themen kommen dazu, alte Antworten stimmen nicht mehr.

Ohne laufende Evaluation lässt sich keine Änderung mehr verantworten: ein neues Modell, ein anderes Chunking, ein zusätzlicher Filter. Man merkt an Einzelfällen, dass etwas anders ist, und kann nicht sagen, ob es besser ist. Ab diesem Punkt wird nichts mehr geändert, und das System altert.

Als Größenordnung: die Pflege von Testsatz und Auswertung ist über die Laufzeit derselbe Aufwand wie die Indexpflege, und beide zusammen übersteigen die Inferenzkosten in fast allen Fällen im Mittelstand.

Lokal oder gehostet ist eine Tauschentscheidung, keine Sparentscheidung

Lokaler Betrieb tauscht laufende Token-Kosten gegen einmalige Anschaffung plus Betrieb. Die begrenzende Größe ist der Videospeicher, weil er bestimmt, welche Modellgröße hineinpasst; Rechengeschwindigkeit entscheidet danach nur über den Durchsatz.

Was in der Rechnung oft fehlt: Strom, Kühlung, Ersatzteile und vor allem jemand, der die Modelle aktualisiert. Ein lokales Modell veraltet, und der Aktualisierungsprozess ist Ihrer.

Was dafür spricht, ist meistens nicht der Preis, sondern dass die Dokumente das Haus nicht verlassen. Das ist eine gute Begründung. Die Ersparnis als Hauptargument trägt nur bei hohem, gleichmäßigem Anfragevolumen.

Die Positionen, nach denen wir ein Angebot durchsuchen würden

Wer pflegt den Index und mit welchem Aufwand pro Monat. Was passiert bei einem Wechsel des Embedding-Modells und wer trägt ihn. Wie wird gemessen, ob das System noch richtig antwortet, und wie oft. Wie werden Rechte abgebildet und wer pflegt sie, wenn sich die Organisation ändert. Und was kostet der Ausstieg, also in welcher Form die Daten und der Index das System verlassen.

Ein Angebot, das diese fünf Fragen beantwortet, ist möglicherweise teurer als eines, das sie nicht stellt. Es ist auch das einzige der beiden, dessen Zahl nach einem Jahr noch stimmt.

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.

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.

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