Pivoa
L'essentiel à retenir
Un agent IA ne devrait pas improviser quand la décision tient dans une liste fermée. Strands Decider vise précisément ces embranchements : choisir une option, répondre par oui ou non, ou attribuer un score selon une échelle définie. Pour une PME belge de 10 à 50 personnes, l'intérêt potentiel est concret : séparer les tâches ouvertes, qui demandent encore un grand modèle génératif, des décisions répétitives que l'on peut davantage observer, mesurer et interrompre.
Le projet présente un modèle de 1,9 milliard de paramètres exploitable localement. Il annonce aussi qu'au-dessus d'une confiance de 0,9, environ 95 % des réponses seraient correctes sur des tâches courtes de classification inédites. Ce sont les résultats du projet, pas une validation indépendante. Le dépôt a été créé le 29 septembre 2026 : il est jeune, et ses chiffres doivent être reproduits sur vos données avant toute décision d'architecture.
Le bon premier usage n'est donc ni le recrutement, ni le crédit, ni une action irréversible. C'est un flux interne étroit, avec peu d'options, un seuil explicite et une reprise humaine. Petit périmètre. Mesure réelle. Droit au refus.
Le problème que ça résout
Dans beaucoup de projets d'agents, le même modèle reçoit tout : comprendre une demande, choisir un outil, contrôler ses arguments, produire une réponse et décider si le travail est terminé. Cette simplicité apparente a un coût. Quand une étape devrait seulement trancher entre « facturation », « vente » et « support », demander du texte libre ajoute une marge d'interprétation dont l'entreprise n'a pas besoin.
Strands Decider part d'une séparation plus nette. Le grand modèle garde les problèmes ouverts. Le modèle de décision reçoit un état, une question et un espace de réponses délimité. Il choisit une option, rend une valeur oui/non ou place le cas sur une échelle ordonnée. La sortie inclut une confiance annoncée comme calibrée par le projet.
Pour une PME belge, le sujet n'est pas de remplacer son système actuel par une nouvelle couche d'IA. Il est de repérer les décisions déjà structurées dans le travail quotidien. Une demande entrante doit-elle aller à la comptabilité ou au service commercial ? Un dossier manque-t-il une pièce attendue ? Une réponse produite par un agent respecte-t-elle une règle interne définie ? Voilà des candidats au test, à condition que les catégories soient connues et que l'erreur reste récupérable.
Le bénéfice recherché est la lisibilité. Une décision bornée se journalise plus facilement qu'un paragraphe libre. On peut conserver l'entrée, les options proposées, le choix obtenu, le niveau de confiance et la décision finale d'un humain. Cela ne rend pas le modèle juste par magie. Cela rend son erreur plus visible et donc plus facile à traiter dans un protocole d'essai.
La confiance n'est d'ailleurs pas une autorisation d'agir. C'est un signal à intégrer dans une règle métier. Sous le seuil choisi par l'entreprise, le flux peut demander une précision, transmettre le cas à une personne ou ne rien faire. Au-dessus du seuil, l'action reste limitée à ce que le test a effectivement couvert. Un score élevé sur une demande de support ne prouve rien sur un autre métier, une autre langue ou des messages plus longs.
Ce que c'est concrètement
Strands Decider est présenté par ses mainteneurs comme un modèle de décision, parfois décrit comme un modèle « système un ». Contrairement à un modèle génératif qui peut produire une suite de texte arbitraire, il travaille sur des sorties encadrées.
Le projet expose trois formes de décision. La première sélectionne une option parmi une liste fournie avec la requête. La deuxième estime une réponse oui/non. La troisième attribue une position sur une échelle ordonnée. Ces formes peuvent servir au routage d'un dossier, à la sélection d'un outil par un agent, au contrôle des arguments d'une action, à une vérification de politique interne ou à l'évaluation d'une réponse. Ce sont des usages proposés par le projet, pas des garanties de performance dans une entreprise donnée.
Le modèle de référence décrit dans le README compte 1,9 milliard de paramètres. Son architecture conserve le corps préentraîné d'un modèle de langage, retire la tête destinée à générer du texte et la remplace par une petite tête qui compare les options. Selon le projet, cette tête représente environ un million de paramètres. L'objectif est de calculer un choix sans boucle de génération. Une adaptation légère du corps du modèle complète l'ensemble.
Les chiffres publiés donnent un ordre de grandeur, avec de fortes limites. Sur le jeu public JevBench mentionné par le projet, la version de référence obtient 167 réponses correctes sur 231 tâches, soit une exactitude annoncée de 0,723. Le dépôt signale lui-même que 231 tâches restent peu nombreuses. Il rapporte aussi qu'une variation inférieure à environ 10 tâches entre deux entraînements isolés doit rester considérée comme non résolue, au vu des variations observées dans ses propres essais.
Côté vitesse, le projet rapporte une médiane de 115 millisecondes par question sur une RTX 3090 sous WSL2 et une médiane à chaud de 153 millisecondes sur un Mac M3 Pro pour les tâches de moins de 300 jetons. Ces mesures dépendent du matériel, du contexte, de la longueur des entrées et du protocole. Elles n'ont pas été validées indépendamment ici. Elles ne doivent donc pas devenir la latence promise à un utilisateur ou inscrite telle quelle dans un dossier d'investissement.
Le dépôt indique enfin que le service peut fonctionner sur un Mac Apple silicon ou sur processeur. Là encore, « fonctionne » ne veut pas dire « respecte votre débit, votre budget énergétique ou vos contraintes d'exploitation ». La seule mesure utile pour votre PME sera celle obtenue sur la machine réellement retenue, avec des données représentatives et le volume attendu.
Comment s'en servir
Étape 1 : choisir une décision vraiment fermée
Commencez par un embranchement existant, pas par un projet d'agent complet. Écrivez la question telle qu'un collaborateur la comprend et listez toutes les réponses autorisées. Si l'équipe ajoute constamment une catégorie « autre », si deux réponses peuvent être vraies à la fois ou si le sens dépend d'une longue négociation, le cas n'est probablement pas assez borné.
Un bon pilote pour une PME de 10 à 50 personnes reste interne et réversible : orienter un message vers une file, signaler qu'une information manque ou proposer un niveau de priorité à confirmer. Le modèle conseille le flux. Il ne prend pas possession du processus.
Étape 2 : constituer un jeu de cas relus
Rassemblez des exemples représentatifs du langage réellement reçu par l'entreprise. Retirez ou protégez les données qui n'ont pas à entrer dans l'essai. Faites ensuite attribuer la bonne réponse par une personne qui connaît le processus. Si les humains ne s'accordent pas sur la catégorie, le modèle ne corrigera pas une règle métier floue.
Séparez les exemples utilisés pour régler le dispositif de ceux qui serviront à l'évaluer. Le but n'est pas d'obtenir une belle démonstration sur quelques formulations connues. Il faut vérifier ce qui se passe avec les fautes, les messages ambigus, le français local, le néerlandais si le flux en contient, et les demandes qui ne rentrent dans aucune option prévue.
Étape 3 : définir le seuil et la sortie de secours
Le projet met en avant une relation entre confiance et exactitude. Son affirmation la plus visible est qu'avec une confiance au moins égale à 0,9, les réponses seraient correctes environ 95 % du temps sur ses tâches courtes inédites. Cette relation doit être recalculée sur votre jeu de cas. Un seuil repris du README ne devient pas automatiquement un seuil métier.
Décidez avant le test ce qui arrive sous ce seuil : demande de précision, classement manuel ou arrêt du flux. Prévoyez aussi le traitement des catégories inconnues. Le refus de décider est une fonction. Sans lui, le système transforme son doute en action.
Étape 4 : faire tourner le pilote en parallèle
Pendant la phase d'observation, conservez la décision humaine comme référence et exécutez le modèle sans lui laisser déclencher seul une conséquence externe. Comparez le choix, la confiance et l'issue validée. Regardez surtout les erreurs qui coûtent réellement du temps ou créent un risque pour le processus.
La moyenne seule masque les cas importants. Une confusion entre deux files internes n'a pas la même portée qu'un faux feu vert avant une opération sensible. Classez donc les erreurs par conséquence, puis ajustez les options, la formulation de la question ou le seuil. Si le modèle reste instable sur une catégorie, cette catégorie retourne à l'humain.
Étape 5 : encadrer le passage en exploitation
Un pilote concluant n'est pas une preuve de préparation à la production. Il reste à définir les journaux, la supervision, la reprise après incident, la version du modèle, les tests lors d'une mise à jour et la personne responsable du seuil. Une petite équipe a justement intérêt à réduire le nombre de composants qu'elle doit surveiller.
Le passage en exploitation doit garder une limite claire : quelles entrées sont acceptées, quelles actions sont permises et dans quels cas l'humain reprend la main. Mesurez ensuite les écarts dans le temps. Le vocabulaire des clients change. Les catégories internes aussi. Une décision bornée aujourd'hui peut devenir ambiguë demain.
Ce que ça coûte vraiment
Le logiciel est public et placé sous licence Apache-2.0 selon le dépôt. Cela ne rend pas le projet gratuit à exploiter. Le coût principal commence là où la démonstration s'arrête.
Il faut d'abord du temps d'intégration. Quelqu'un doit relier le modèle au flux existant, formater les entrées, définir les options, enregistrer les résultats et construire le chemin de reprise. Dans une PME de 10 à 50 personnes, ce travail concurrence directement d'autres priorités. Un composant léger peut donc coûter cher s'il ajoute une nouvelle chaîne technique que personne ne possède vraiment.
L'exploitation locale déplace aussi les responsabilités. L'entreprise choisit la machine, installe l'environnement, protège les données, suit la consommation de ressources et gère les mises à jour. Le projet annonce un fonctionnement possible sur processeur, sur Mac Apple silicon et sur certains GPU dans ses essais. Le matériel à retenir, son prix et sa capacité ne peuvent pas être déduits de ces seules indications. Ils doivent être mesurés sur place, sans montant inventé.
Vient ensuite le coût de la compétence. Il faut comprendre la différence entre confiance du modèle, exactitude observée et risque métier. Il faut aussi savoir construire un jeu d'évaluation, lire les faux positifs et décider quand une variation justifie un retour en arrière. Sans cette compétence, le seuil devient un chiffre décoratif.
La maintenance compte autant que le premier branchement. Chaque changement de version, de catégorie ou de formulation peut modifier les résultats. Le projet est né le 29 septembre 2026. Son historique est encore court, même si les mainteneurs documentent leurs essais et leurs échecs. Une PME doit prévoir le gel d'une version testée, la reproduction des mesures après changement et une solution de repli si le composant ne répond plus comme attendu.
Enfin, le coût doit être comparé à une alternative simple. Une règle déterministe, un formulaire mieux conçu ou un classifieur traditionnel déjà maîtrisé peut suffire. Le README positionne le modèle entre grand modèle génératif et classifieur entraîné pour une tâche. Cette place est intéressante quand les catégories changent ou quand l'on veut tester vite. Elle ne dispense pas de vérifier si quelques règles explicites font mieux, avec moins de maintenance.
Pour qui ce n'est pas
Ce projet n'est pas adapté à une décision dont les réponses possibles ne peuvent pas être énumérées proprement. Si le travail consiste à négocier, expliquer, créer, synthétiser un dossier complexe ou découvrir une intention absente des catégories, un décideur borné force le réel à entrer dans une mauvaise case.
Il ne convient pas non plus aux équipes qui cherchent un composant prêt à mettre en production. Le dépôt est très récent. Ses performances, sa calibration et ses temps de réponse sont publiés par le projet. Ils doivent être reproduits de manière indépendante dans le contexte visé.
Écartez aussi, au moins au départ, les décisions à fort impact sur une personne ou une entreprise : recrutement, accès à un service essentiel, crédit, sanction, conseil juridique ou action difficile à annuler. Le modèle peut produire une confiance élevée et se tromper. Une sortie numérique ne remplace ni la responsabilité, ni l'examen du dossier, ni les contrôles applicables à votre activité.
Enfin, ce n'est pas le bon choix si personne ne peut entretenir le jeu de tests, examiner les erreurs et assumer le seuil. Dans une petite structure, la sobriété technique est une force. Ajouter un modèle parce qu'il est petit reste ajouter un modèle.
Source : https://github.com/strands-labs/strands-decider
FAQ
Strands Decider remplace-t-il un grand modèle de langage ?
Non. Il vise les étapes où la sortie est déjà encadrée : choisir parmi des options, estimer oui/non ou noter sur une échelle. Un grand modèle reste plus adapté aux demandes ouvertes et à la génération de texte. Les deux peuvent coexister dans un même flux, chacun sur un rôle limité.
Peut-on reprendre le seuil de confiance de 0,9 ?
Pas comme règle prête à l'emploi. Le projet associe ce seuil à environ 95 % de réponses correctes sur ses tâches courtes inédites, mais cette métrique n'est pas validée indépendamment ici. Il faut mesurer la calibration sur vos données, puis choisir le seuil selon le coût des erreurs et la reprise humaine disponible.
Faut-il un GPU pour l'essayer ?
Le dépôt affirme que le modèle peut aussi fonctionner sur un Mac Apple silicon ou sur processeur. Cela ne garantit ni un débit ni un temps de réponse adapté à votre flux. Le test doit se faire sur le matériel envisagé, avec la longueur des messages et le volume propres à l'entreprise.
Quelles décisions tester en premier dans une PME belge ?
Privilégiez un routage interne, une vérification de complétude ou une priorité proposée à un collaborateur. La bonne première décision a des options stables, des exemples déjà relus, une erreur réversible et une personne capable de reprendre la main.
Comment savoir si le pilote est concluant ?
Fixez les critères avant de lancer l'essai : types d'erreurs acceptables, cas qui imposent une reprise humaine, comportement sous le seuil et procédure en cas de catégorie inconnue. Comparez ensuite le modèle aux décisions relues et à une solution plus simple. Décider, mesurer, renoncer si nécessaire : le petit modèle n'a de valeur que s'il rend le processus plus maîtrisable.
Publié le 2 octobre 2026.
Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.
