Et si l’étape la plus chère d’un agent n’était pas de rédiger, mais simplement de choisir ? Pendant des mois, les équipes produit ont demandé à des modèles géants de trancher entre trois boutons, deux outils ou quatre intentions, comme on demanderait à un orchestre de jouer une note. Le résultat fonctionne, mais il coûte, il traîne, et il s’égare parfois hors du cadre. C’est dans ce décalage qu’une jeune pousse, TypeSafe, a planté une idée assez simple pour paraître évidente, et assez précise pour déclencher une ruée. Amazon vient d’y répondre avec son propre clone ouvert. Le web des agents se remplit soudain de petits cerveaux qui ne parlent presque pas, mais qui décident très vite.

Le geste n’est pas anodin. Lorsqu’un géant du cloud publie un modèle de deux milliards de paramètres, inspiré d’une architecture née chez une startup, et qu’il le fait la même semaine qu’un laboratoire de frontière annonce une offre voisine, le signal dépasse le communiqué. On n’assiste plus à une curiosité de chercheurs. On voit une catégorie se solidifier : des modèles de décision calibrés, bornés, conçus pour l’automatisation plutôt que pour la conversation. Le reste de cet article raconte comment cette catégorie est née, pourquoi elle séduit les workflows, et ce qu’elle change pour celles et ceux qui construisent encore des produits agents.

Pourquoi Un Petit Décideur Vaut Parfois Un Grand Modèle

Un agent moderne n’est pas un monologue. C’est une chaîne. Il observe un état, sélectionne une action, appelle un outil, relit un résultat, puis recommence. Dans cette boucle, une fraction des appels exige vraiment de la rédaction, du raisonnement ouvert ou une connaissance rare. Le reste consiste à classer. Faut-il relancer une recherche, demander une précision, exécuter le paiement, ou s’arrêter ? Le domaine des réponses est fermé. Le besoin, lui, est de fiabilité et de vitesse.

Les grands modèles de langage excellent à produire du texte. Ils sont moins à l’aise lorsqu’on leur demande de rester dans une liste et de dire, sans théâtre, à quel point ils sont sûrs. On peut les contraindre par des consignes, des schémas ou des fonctions. On paie alors la contrainte au prix fort : latence, tokens, et une confiance souvent mal étalonnée. Un modèle spécialisé inverse la logique. Il conserve le socle d’un modèle de langage, ce que les équipes appellent parfois le torse, puis remplace la génération libre par une sortie de choix calibrée.

C’est exactement le terrain sur lequel TypeSafe a lancé Jev. Le nom n’est pas un acronyme marketing. Il renvoie à l’économiste William Stanley Jevons, et à une idée contre-intuitive : quand le coût d’une ressource chute, sa consommation peut augmenter au lieu de baisser. Appliquée à l’intelligence machine, la thèse est claire. Si décider devient presque gratuit, on décidera partout, à chaque micro-étape, et non plus seulement aux moments solennels d’un parcours.

Le Pari De TypeSafe, Avant La Ruée

TypeSafe n’a pas inventé le classement de textes. Les classifieurs existent depuis des décennies. Ce qui change, c’est le point de départ. Plutôt que d’entraîner un étiqueteur étroit sur un jeu figé, la startup part d’un modèle déjà instruit, capable de lire plusieurs langues et de reconnaître des contextes variés, puis elle le plie vers une tâche unique : choisir parmi des options préparées, et accompagner ce choix d’un score de confiance utile.

Le fondateur et dirigeant, Diogo Almeida, a décrit la suite avec une lucidité que beaucoup de communiqués évitent. Voir des dizaines de variantes apparaître peut ressembler à une ruée vers l’or. Selon lui, cette impression sous-estime la difficulté de rendre ces modèles réellement intelligents. La fournée actuelle, ajoutait-il, ressemble davantage à des praticiens d’apprentissage automatique qui veulent tester une architecture élégante qu’à des équipes obsédées par l’utilité. La phrase pique. Elle dit aussi quelque chose de vrai sur le moment : cloner une idée est devenu bon marché, la rendre robuste en production l’est beaucoup moins.

On peut prendre la vague pour une ruée vers l’or, mais rendre ces modèles vraiment intelligents reste un métier, pas un simple exercice d’architecture.

Diogo Almeida, fondateur de TypeSafe, propos reformulé

Cette position n’est pas défensive par réflexe. Elle dessine une frontière. D’un côté, la démonstration : un petit modèle qui bat un classement public sur une taille donnée. De l’autre, le produit : une calibration qui tient quand les options changent, quand la langue glisse, quand l’état de l’agent est bruité. TypeSafe affirme rester concentrée sur les prochaines versions. Amazon, de son côté, n’a pas attendu pour occuper le terrain ouvert.

Comment Amazon A Transformé Un Bricolage En Offre Ouverte

L’histoire interne commence par une lecture. Marc Brooker, ingénieur distingué chez Amazon, voit Jev, tente sa propre version, et obtient un résultat assez convaincant pour grimper, un temps, en tête d’un classement nommé Jevbench dans sa catégorie de taille. Le bricolage ne reste pas dans un carnet. Des équipes le nettoient, le stabilisent, puis le publient sous la bannière de Strands Labs, le groupe qui explore outils et protocoles pour déployer des agents.

Le modèle s’appelle Strands Decider 2B. Il s’appuie sur le torse de Qwen3.5-2B. Il est ouvert, disponible, et assez compact pour tourner en local. La promesse tient en trois traits : trier des options déjà posées, le faire vite, et rendre un degré de certitude. Rien de spectaculaire à lire. Beaucoup à brancher dans une étape de workflow.

Brooker relie le besoin à des échanges avec des clients du cloud. Leurs parcours agents n’exigent pas, à chaque nœud, la puissance ni la facture d’un grand modèle. Ce qui l’a accroché, c’est l’idée d’un décideur d’étape : que faire ensuite, sachant où l’on est. Le cadre fermé, le score de confiance et la latence basse rendent l’étape plus structurable, donc plus fiable, et potentiellement moins chère.

Le bon usage, c’est l’étape de workflow : quelle est la prochaine action, vu l’état actuel, avec un domaine de réponses fermé et une confiance lisible.

Marc Brooker, ingénieur distingué Amazon, propos reformulé

Il insiste aussi sur un équilibre fragile. Pousser la justesse et la calibration sur ces tâches ne doit pas abîmer la compréhension des langues ni le socle de connaissances qui rend le modèle généraliste. Trop spécialiser, et l’outil devient un classifieur myope. Trop préserver la génération, et l’on retombe dans la lenteur que l’on voulait éviter. Cette tension explique pourquoi la catégorie peut sembler saturée de clones sans être pour autant résolue.

Ce Que Fait Vraiment Un Modèle De Décision

Pour éviter le flou, il faut décrire le geste technique sans jargon inutile. On part d’un modèle déjà entraîné à lire le monde en tokens. On lui retire, ou l’on court-circuite, la tête qui prolonge une phrase mot après mot. À la place, on apprend une sortie qui pointe vers une option parmi N, parfois avec une abstention, et l’on ajuste les probabilités pour qu’elles correspondent mieux à la fréquence réelle de réussite. Ce dernier point a un nom : la calibration. Un modèle calibré qui annonce 80 % de confiance a, sur le long cours, raison environ huit fois sur dix.

Cette propriété change le design des agents. Sans calibration, un score n’est qu’un ornement. Avec elle, on peut écrire des règles. Au-dessus d’un seuil, on exécute. Entre deux seuils, on demande une confirmation. En dessous, on escalade vers un modèle plus large, ou vers un humain. Le petit décideur ne remplace pas la frontière. Il trie le trafic.

  • Le domaine est fermé : les réponses admissibles sont posées avant l’appel.
  • La sortie est un choix, pas un paragraphe à parser.
  • La confiance est faite pour être branchée sur une politique, pas pour décorer une interface.
  • La latence vise l’étape répétée, celle qui se joue des centaines de fois par session.
  • Le socle linguistique reste utile pour lire des états mal formulés.

On mesure mieux, dès lors, l’écart avec un grand modèle qu’on force à répondre en JSON. Le schéma aide, mais le modèle continue de « penser » comme un générateur. Il peut inventer une clé, adoucir un refus, ou produire une confiance décorrélée. Le décideur spécialisé est plus ennuyeux. C’est précisément son métier.

Le Paradoxe De Jevons, Appliqué Aux Agents

L’hommage à Jevons n’est pas une coquetterie. Au XIXe siècle, l’économiste observait que des machines à vapeur plus efficaces ne réduisaient pas la consommation de charbon : elles élargissaient les usages. Le parallèle avec l’inférence est devenu un lieu commun des débats sur l’énergie des centres de données. Ici, il vise autre chose : la demande de micro-décisions.

Tant qu’un appel coûte plusieurs secondes et plusieurs centimes, on regroupe les choix. On demande au grand modèle de planifier cinq étapes d’un coup. On accepte des plans fragiles pour économiser des allers-retours. Si un décideur local répond en une fraction de ce temps, pour une fraction de ce prix, l’architecture se déplie. Chaque outil, chaque garde-fou, chaque branche d’un graphe peut interroger un petit modèle. La consommation totale d’« intelligence de tri » monte, même si chaque unité baisse.

C’est une bonne nouvelle pour les produits qui vivent d’itérations serrées : support, ops internes, extraction documentaire, orchestration d’API. C’est une nouvelle plus ambivalente pour les factures d’énergie et pour la gouvernance. Multiplier les points de décision, c’est aussi multiplier les endroits où une confiance mal réglée peut dévier un parcours. Le paradoxe ne dit pas que moins cher signifie plus sage. Il dit que moins cher signifie plus fréquent.

Pourquoi La Même Semaine Compte

Strands Decider sort la même semaine qu’une annonce comparable chez OpenAI. Le détail de l’offre du laboratoire importe moins, ici, que la coïncidence. Quand un cloud ouvert et un laboratoire fermé occupent le même créneau au même moment, la catégorie cesse d’être une niche de papier. Les équipes produit reçoivent le message : il existe désormais un slot standard, entre le routeur de règles et le modèle frontière.

Ce slot a un profil économique particulier. Brooker note que, sur des marchés plus étroits, bâtir quelque chose d’intéressant peut se chiffrer en centaines ou en milliers de dollars, pas en campagnes d’entraînement de frontière. La phrase relativise la peur d’un verrouillage. Elle relativise aussi l’avantage d’être premier. Si le ticket d’entrée est bas, la file des clones s’allonge. La différenciation se déplace vers les données d’évaluation, la calibration par domaine, et l’intégration dans les runtimes d’agents.

TypeSafe le sait. Amazon aussi. L’un mise sur la profondeur d’une ligne de modèles. L’autre sur la distribution : un artefact ouvert, proche des clients qui déploient déjà des agents sur son cloud, rattaché à un laboratoire interne nommé Strands. Aucun des deux discours n’annule l’autre. Ils décrivent deux couches d’une même pile.

Tableau Clair : Où Placer Le Décideur

Avant d’entrer dans les cas d’usage, un repère aide à ne pas tout mélanger. Le décideur n’est ni un routeur statique, ni un planificateur, ni un rédacteur. Le tableau ci-dessous reste volontairement concret.

CoucheCe qu’elle trancheForceLimite
Règles fixesCas connus, seuils dursGratuit, auditableFragile dès que le langage varie
Modèle de décisionChoix fermé et confianceVite, local, calibrableNe rédige pas, n’invente pas d’option
Modèle intermédiaireReformulation, extraction courteBon compromis coûtConfiance souvent décorative
Modèle frontièrePlan ouvert, cas raresÉtendue et nuanceLatence, prix, dérive hors cadre
HumainAmbiguïté coûteuseResponsabilitéNe scale pas sur la micro-étape

Lue ainsi, la sortie d’Amazon n’est pas une attaque contre les grands modèles. C’est un étage manquant. Les clients qui « n’ont pas toujours besoin » d’un LLM complet ne disent pas qu’ils n’en ont jamais besoin. Ils disent que la boucle est mal taillée si chaque carrefour appelle le même moteur.

Cinq Endroits Où Le Décideur Change La Boucle

Le discours reste abstrait tant qu’on ne pose pas le composant dans des parcours réels. Voici cinq endroits où le gain n’est pas théorique. Aucun n’exige d’inventer une capacité magique. Tous exigent un domaine de réponses écrit à l’avance.

Routage d’intention. Un message arrive. Les issues possibles sont limitées : facturation, incident technique, demande commerciale, hors sujet. Un grand modèle peut le faire. Un décideur calibré le fait assez souvent pour absorber le flot, et assez humblement pour renvoyer les cas limites. Le score devient la politique, pas un badge affiché à l’utilisateur.

Choix d’outil. L’agent dispose de quatre connecteurs. L’état courant indique lequel appeler, ou s’il faut d’abord clarifier. La tentation classique est de laisser le modèle frontière « décider en parlant ». Le décideur force la liste. On gagne une trace : option retenue, confiance, et seuil qui a autorisé l’appel.

Garde de sécurité légère. Avant d’envoyer une action irréversible, une étape demande : conforme, à reformuler, ou à bloquer. Ce n’est pas un substitut à une politique de sûreté sérieuse. C’est un filtre rapide qui évite d’occuper le grand modèle pour des évidences, et qui documente pourquoi l’on a escaladé.

Reprise après outil. Une API répond vide, partielle, ou en erreur. Les suites possibles sont reprises, changement d’outil, ou abandon propre. Décider cela en local, près du runtime, réduit les allers-retours vers une région lointaine. Sur des chaînes longues, ces micro-choix dominent le temps perçu.

Arrêt de boucle. Les agents qui tournent trop sont un classique des démonstrations ratées. Un décideur dont le travail est seulement de dire continuer, clarifier ou terminer, avec une confiance suivie dans le temps, donne un frein mesurable. On peut alors auditer les arrêts, pas seulement les admirer quand ils tombent juste.

Ces cinq usages partagent une discipline. Quelqu’un a écrit les options. Quelqu’un a fixé les seuils. Quelqu’un relit les erreurs. Le modèle n’absout pas la conception. Il la rend exécutable à un coût qui autorise la répétition.

Le Classement, Le Bricolage, Et Ce Qu’ils Ne Prouvent Pas

Le prototype interne d’Amazon a brièvement dominé Jevbench pour sa taille. Le fait mérite d’être cité, et tout de suite encadré. Un banc public, sur une famille de tâches, dit qu’une recette tient la route face à des pairs de gabarit voisin. Il ne dit pas que le modèle survivra au vocabulaire d’un service financier, ni qu’il restera calibré après un changement de consignes, ni qu’il comprendra un état d’agent rédigé à la va-vite par un autre modèle.

C’est le cœur de la mise en garde d’Almeida. Implémenter une architecture élégante est devenu un week-end pour une équipe outillée. Constituer des jeux d’évaluation qui ressemblent à la production, mesurer la calibration par tranche de confiance, et tenir la qualité quand on ajoute une langue ou un métier : voilà le travail qui ne se clone pas en copiant des poids. La ruée prouve l’intérêt. Elle ne prouve pas la maturité.

Brooker, de son côté, ne promet pas que les laboratoires de frontière abandonneront le créneau. Il doute simplement qu’ils le dominent par défaut, parce que le marché unitaire est plus mince et le coût d’une tentative intéressante étonnamment bas. Les deux lectures se complètent. La frontière peut publier un décideur généraliste très propre. Une startup peut gagner sur un vertical où les erreurs ont un prix connu. Un cloud peut gagner sur la distribution et le local.

Ouvert, Local, Et Assez Petit Pour Sortir Du Datacenter

Strands Decider est pleinement ouvert et assez compact pour une exécution locale. Le détail compte plus que le slogan. Un décideur qui doit voyager vers une API distante à chaque carrefour reperd une partie de l’avantage de latence. Un décideur qui tourne à côté du runtime, sur la même machine que l’orchestrateur, transforme le choix en appel de fonction. Pour des agents internes, des postes de développement, ou des environnements qui ne veulent pas sortir certaines données, la différence est concrète.

L’ouverture change aussi le rapport de force avec la startup d’origine. TypeSafe peut continuer à améliorer une ligne propriétaire ou semi-ouverte. Amazon place un point de référence que n’importe quelle équipe peut forker, mesurer, et spécialiser. Dans les catégories d’outils pour agents, ce schéma s’est déjà vu : le premier nomme le problème, le second le rend banal, le troisième le fond dans un framework. Strands Labs, précisément, travaille outils et protocoles de déploiement. Publier le décideur là n’est pas un à-côté. C’est un composant de pile.

Il reste une réserve. Ouvert ne signifie pas neutre. Le torse vient de Qwen3.5-2B. Les biais, les trous de connaissance et les forces linguistiques de ce socle voyagent avec le décideur. Les équipes qui l’adoptent héritent d’un profil, pas d’une page blanche. D’où l’insistance de Brooker : ne pas sacrifier la compréhension générale en chassant le point de bench.

Ce Que Les Startups Peuvent Encore Tenir

La question qui suit toute annonce d’un géant est brutale : reste-t-il une place ? Sur ce créneau, la réponse est oui, à condition de ne pas vendre « un clone de plus ». Les marges se situent là où le cloud généraliste ne veut pas s’alourdir.

D’abord, l’évaluation métier. Un banc générique ne connaît pas les libellés d’un assureur, les codes d’un logisticien, ni les tournures d’un support en plusieurs langues régionales. Une startup qui apporte des jeux vivants, des seuils par segment, et une revue d’erreurs lisible vend de la confiance opérationnelle, pas des poids.

Ensuite, la politique. Brancher un score sur une action irréversible demande un produit autour du modèle : journaux, rebonds, simulations, droits. Le modèle ouvert d’Amazon donne le moteur. Il ne donne pas le tableau de bord que le responsable risque d’une scale-up voudra montrer à son conseil.

Enfin, la spécialisation étroite. Almeida a raison de distinguer l’exercice d’architecture et le métier de l’utile. Une équipe qui passe ses semaines sur la calibration d’un seul domaine, avec des clients qui paient les erreurs, accumule un avantage que ni un week-end de fork ni un communiqué de cloud ne copient vite. Le risque, pour ces équipes, est de confondre visibilité et distribution. Amazon n’a pas besoin d’être le meilleur décideur du banc pour devenir le défaut dans des milliers de comptes.

  • Ne pas concurrencer le prix du gratuit ouvert sur le cas général.
  • Vendre le jeu d’évaluation et la politique, pas seulement les poids.
  • Choisir un vertical où l’erreur a un coût que le client sait nommer.
  • Prévoir la coexistence : petit décideur local, grand modèle en escalade.
  • Documenter la calibration comme on documente un taux de service.

Les Pièges Que La Ruée Va Répéter

Une catégorie qui se remplit vite répète les mêmes erreurs. La première est de prendre la confiance affichée pour une probabilité. Sans mesure sur ses propres données, un 0,9 n’est qu’un nombre arrondi. La deuxième est d’élargir les options en silence. Un décideur entraîné sur six issues se dégrade si l’on en ajoute quatre dans le prompt sans réévaluation. La troisième est de le laisser rédiger « un peu », par confort, jusqu’à reconstituer le problème que l’on fuyait.

Il y a aussi le piège du bench unique. Grimper Jevbench, ou n’importe quel cousin, rassure une démo. Cela ne remplace pas une courbe de fiabilité, ces diagrammes où l’on compare confiance annoncée et justesse observée par tranche. Une startup sérieuse montrera cette courbe. Un intégrateur sérieux la redessinera après chaque changement de domaine.

Dernier piège, plus politique : croire que le local dispense de gouvernance. Un modèle qui tourne sur la machine du développeur peut quand même orienter des actions clients. L’ouverture facilite l’audit des poids. Elle ne rédige pas la politique d’usage. Les équipes qui traitent le décideur comme une bibliothèque anodine découvriront, au premier incident, qu’une micro-décision répétée des milliers de fois pèse autant qu’une grande réponse spectaculaire.

Comment Lire L’Équilibre Que Brooker Décrit

La phrase la plus utile de l’annonce n’est pas le nom du modèle. C’est l’équilibre. On veut monter la justesse et la calibration sur le tri, sans abîmer les langues ni le fonds de connaissances qui rendent l’outil généraliste. Traduit en choix d’ingénierie, cela veut dire résister à deux tentations opposées.

La première tentation est le sur-ajustement. On fine-tune jusqu’à ce que le banc interne soit parfait, et l’on découvre que le modèle ne comprend plus une formulation légèrement décalée. La deuxième est la paresse du socle. On garde presque intact un générateur, on ajoute une tête de classement légère, et l’on espère que la calibration viendra toute seule. Elle ne vient pas. La calibration est un objectif, pas un effet secondaire.

Pour un lecteur non spécialiste, l’image utile est celle d’un chef d’orchestre qu’on aurait formé à ne jouer que les entrées. Il doit encore entendre toute la partition, sinon il rate le moment. Mais s’il se remet à improviser un solo, il a quitté son poste. Les bons décideurs entendent large et jouent étroit. C’est plus difficile à entraîner que l’un ou l’autre extrême, et c’est exactement pourquoi Almeida peut soutenir qu’il ne voit pas encore de concurrence réelle, pendant qu’Amazon publie déjà un clone crédible. Les deux énoncés peuvent être vrais en même temps : beaucoup de clones, peu d’équipes dédiées à l’utile.

Une Méthode Simple Pour Tester Sans Se Racontre D’histoires

Les équipes qui voudront essayer Strands Decider, Jev, ou le cousin annoncé côté OpenAI, gagneront à suivre un protocole court plutôt qu’une démo flatteuse. Le but n’est pas de couronner un gagnant universel. Le but est de savoir si le composant mérite une place dans une boucle donnée.

On commence par écrire les options comme on écrirait un contrat. Pas de catégorie fourre-tout nommée « autre » qui avale un tiers du trafic sans revue. On constitue ensuite un échantillon réel, pas seulement des phrases d’exemple. On mesure la justesse globale, puis la justesse par option, car les classes rares mentent dans les moyennes. On trace la calibration. On fixe deux seuils, exécution et escalade, et l’on calcule le coût complet : décideur plus escalades, contre grand modèle systématique. Enfin, on rejoue après avoir légèrement reformulé les options. Si la courbe s’effondre, le modèle n’était pas prêt pour le produit.

Ce protocole tient en une semaine pour une équipe déjà outillée. Il évite le faux débat entre « les petits modèles suffisent » et « seuls les grands comprennent ». La bonne question est plus étroite : sur cette étape, avec ces issues, le décideur réduit-il le coût sans augmenter les erreurs coûteuses ? Si la réponse est non, on garde le grand modèle. Si elle est oui, on vient d’appliquer, sans le nommer, le pari de Jevons : une décision moins chère, appelée plus souvent, dans un cadre qui reste lisible.

Ce Que Cette Vague Dit Du Marché Des Agents

Regarder uniquement Amazon ou uniquement TypeSafe rate le mouvement. Des dizaines de modèles voisins sont apparus depuis la première sortie de Jev. Le chiffre importe moins que le réflexe. Dès qu’une tâche d’agent se laisse décrire comme un choix fermé, quelqu’un en fait un artefact. La pile des agents cesse d’être un seul appel prestigieux. Elle devient un orchestre de spécialisations bon marché, dont le décideur est la plus austère, et peut-être la plus rentable.

Pour les investisseurs, le filtre change. Financer « un LLM de plus » sur ce créneau a peu de sens si le ticket technique est bas et la distribution captée par les clouds. Financer la couche qui rend le score actionnable, le vertical qui possède les erreurs, ou le runtime qui orchestre décideur et frontière, reste cohérent. Pour les équipes produit, le filtre est plus simple. Chaque étape qui n’écrit pas doit justifier pourquoi elle paie encore un générateur.

Amazon a rendu cette question impossible à ignorer, en publiant un outil que l’on peut lancer sans contrat et sans théâtre. TypeSafe a rendu la question pensable, en nommant la catégorie d’après un paradoxe économique plutôt que d’après une taille de paramètres. OpenAI, la même semaine, a confirmé que le créneau n’était pas un à-côté de blog technique. Le reste appartient aux équipes qui accepteront l’ennui fécond du choix calibré.

Une Scène Concrète, Pour Finir De Voir

Imaginons un agent de relance interne, dans une entreprise qui traite des dossiers incomplets. À chaque document, trois suites existent : demander la pièce manquante, escalader vers un analyste, ou classer sans suite. Avant la vague des décideurs, le flux appelle un grand modèle, qui rédige parfois une justification élégante et choisit parfois de travers, parce que la consigne et le style se mêlent. Après, un petit modèle lit l’état, pointe une des trois issues, et rend une confiance. Au-dessus du seuil, l’action part. En dessous, le grand modèle n’intervient que pour les dossiers ambigus, et rédige alors la note que l’analyste lira vraiment.

Rien dans cette scène n’exige un exploit. Tout exige la discipline que Brooker et Almeida, chacun à sa manière, décrivent. Options fermées. Confiance branchée. Socle encore capable de lire des dossiers mal écrits. Et une équipe qui ne confond pas la facilité de cloner avec la difficulté de tenir juste. C’est là, plus que dans le nom du clone, que la catégorie va se trier.

Le web peut bien se remplir de décideurs. La question utile, pour une startup comme pour un cloud, reste la même que celle posée à l’agent : quelle est la prochaine action, vu l’état réel, et avec quelle confiance mérite-t-elle d’être exécutée sans rappeler tout l’orchestre ?

]]>