Les 5 niveaux des agents IA : du prompt à la production

Il y a cinq mots que tout le monde balance à tort et à travers en ce moment quand on parle d'agents. Context engineering, loop engineering, Jev engineering, harness engineering, eval engineering.

On dirait cinq approches concurrentes. Ce n'est pas le cas. Ce sont cinq couches d'un même système, et chacune répond à une question précise.

Le plus simple pour les comprendre, c'est d'imaginer que vous venez d'embaucher un nouveau collaborateur :

• Context – ce qu'il y a sur son bureau quand vous lui posez une question
• Loop – s'il suit votre checklist ou s'il trouve lui-même l'étape suivante
• Jev – l'accueil qui trie le courrier, pour qu'il ne voie que l'essentiel
• Harness – son bureau. Les outils, les clés, et la personne qui vérifie son travail
• Evals – le même test tous les mois, pour savoir s'il s'est vraiment amélioré

Un agent IA, c'est ce collaborateur. Le modèle, c'est la personne, et ces cinq couches, c'est tout ce qui l'entoure. Maîtrisez ces cinq couches, et une petite équipe peut absorber une charge de travail qui nécessitait avant des recrutements. Le travail répétitif part chez un agent solide en production, et vos équipes gardent la main sur les décisions. Voilà concrètement à quoi ressemble la croissance sans gonfler les effectifs.

Pour chaque couche, je vais décortiquer ce que c'est, comment ça marche, où l'utiliser et comment la construire.

Et pour chaque couche, j'ai aussi préparé un raccourci. Une façon plus simple d'obtenir le même résultat sans tout bâtir de zéro, pensée pour les débutants. Mes amis de Viktor m'ont aidé à assembler ces raccourcis.

Viktor est un employé IA qui vit dans votre Slack ou Microsoft Teams. Il est présent dans les mêmes canaux que tout le monde et travaille comme un coéquipier, celui que vous ajoutez à l'équipe sans avoir à ouvrir un nouveau poste.

Travailler avec lui, c'est comme travailler avec quelqu'un :

• Vous le mentionnez dans un canal ou un fil de discussion et vous décrivez la tâche.
• Il détermine les étapes, exécute le travail à travers vos outils et publie le résultat directement dans le même fil.

La configuration est simple. Ajoutez Viktor à votre espace de travail, et il apparaîtra comme participant, exactement comme n'importe quel membre de votre équipe. Si vous voulez le tester pendant votre lecture, utilisez le code YARCHI100.

pic1. Les cinq couches d'un agent

1. Le context engineering

Définition

Avant chaque question, vous posez des dossiers sur le bureau du collaborateur. Mettez-y les trois bonnes pages, et il vous répond en quelques secondes. Posez-en trois cents, et la réponse se retrouve enterrée au milieu de la pile. Elle lui passe sous le nez.

Le modèle, c'est le collaborateur. Le bureau, c'est la fenêtre de contexte : tout ce que le modèle voit avant de répondre. Vos instructions, la conversation jusqu'ici, les documents extraits d'une base de données, le résultat de chaque outil qu'il a lancé.

Le context engineering, c'est décider de ce qu'on met sur le bureau, et à quel endroit.

Comment ça marche

Plus de contexte ne veut pas dire de meilleures réponses. Au-delà d'un certain point, ça veut dire de moins bonnes.

Stanford l'a testé directement. Donnez 20 à 30 documents à un modèle, et sa précision sur ceux situés au milieu chute à environ 50-57 %. Sans aucun document, ce même modèle obtenait 56 %. La réponse était pourtant dans la fenêtre, et le modèle a fait pire que s'il n'avait rien eu.

Deux choses expliquent cela :

• Les modèles accordent le plus d'attention au début et à la fin de la fenêtre, et le moins au milieu.
• Chaque token coûte de l'argent et du temps, qu'il soit utile ou non.

La seule mécanique qui vaut vraiment le coup d'être connue, c'est le prompt caching. Le fournisseur stocke le début de votre prompt et le réutilise lors de l'appel suivant ; un token mis en cache coûte environ dix fois moins cher qu'un token frais.

Le piège : le cache ne fonctionne que si ce début est strictement identique, octet par octet. Modifiez un seul caractère vers le haut, et tout ce qui suit est facturé plein tarif. L'ordre est donc toujours le même : d'abord les éléments stables, ensuite les éléments variables.

Comment le construire

Chaque élément de contexte va dans l'un de ces quatre emplacements :

1. Le system prompt. Uniquement ce qui reste vrai à chaque appel : rôle, contraintes, format de sortie. Gardez-le identique octet par octet. Pas d'horodatage au début, pas de clés JSON dans un ordre aléatoire.
2. Les outils. Ne les ajoutez pas et ne les supprimez pas en pleine conversation. Cela casse le cache et pousse le modèle à appeler des outils qui n'existent plus. Pour restreindre un outil à une certaine étape, bloquez l'appel mais gardez la définition.
3. Le disque. Tout ce qui est volumineux ou durable part dans un fichier, et seul le chemin reste dans la fenêtre. Même chose pour une page web : gardez l'URL, retirez le corps. Supprimez le contenu, gardez la clé qui permet de le récupérer.
4. La fin (tail). Toutes les quelques étapes, reformulez l'objectif actuel près de la fin du contexte. Vous ne pouvez pas corriger le milieu, alors gardez l'essentiel en dehors de cette zone.

Les outils ont eux aussi une limite. Anthropic a mesuré que 58 définitions d'outils consommaient environ 55 000 tokens avant même que l'utilisateur ait tapé un mot. Laisser le modèle chercher les outils au lieu de tous les charger a fait passer Opus 4 de 49 à 74 % sur leur benchmark.

En dessous d'environ 20 outils, gardez-les chargés. Au-delà, passez à la recherche.

Une dernière astuce pour les gros chantiers : envoyez un sous-agent. Il lit les 50 fichiers dans sa propre fenêtre et vous renvoie un résumé d'une page. Votre contexte principal ne voit jamais que ce résumé.

pic2. Ce qui entre dans un appel de modèle

Le raccourci

Viktor vous soulage de la majeure partie de ce travail, car son contexte vit au niveau de l'entreprise.

• La mémoire. Il conserve une mémoire persistante de votre activité pour toute l'équipe. Ce qu'il a appris de votre cofondateur la semaine dernière n'a pas besoin d'être copié-collé dans votre requête d'aujourd'hui.
• Les sources connectées. Avec Notion, Google Drive ou HubSpot connectés, vous arrêtez de coller des fichiers dans le chat. Vous nommez le document ou l'enregistrement, et il lit la source. C'est la règle du disque, appliquée pour vous.
• Les skills. Vous enregistrez votre écran en train de faire une tâche une seule fois. Il transforme l'enregistrement en procédure écrite, vous la corrigez et la validez. À partir de là, cette instruction est figée et vérifiée, comme un bon system prompt.

Ce qu'il vous reste à faire :

• Rédiger une courte fiche entreprise une seule fois : ce que vous vendez, qui achète, quels chiffres comptent, ce qu'il ne doit absolument jamais faire.
• Une tâche par fil de discussion, avec la définition de « terminé » dès le premier message.
• S'il a mal appris quelque chose, effacez sa mémoire depuis les paramètres au lieu de le corriger dans chaque fil.

2. Le loop engineering

Définition

Vous pouvez donner une checklist au collaborateur : ouvre le fichier, modifie la ligne 12, sauvegarde. Ou vous pouvez lui donner un objectif : fais passer le test.

Avec un objectif, il essaie quelque chose, observe ce qui se passe et décide de la suite. La checklist est un workflow. L'objectif est une boucle.

Comment ça marche

Une boucle, c'est quatre mouvements qui se répètent : penser, agir, observer, décider. Corriger un bug ressemble à ceci :

1. Lance les tests. Trois échouent.
2. Lit la première erreur. C'est un import manquant.
3. Ajoute l'import, relance.
4. Un test échoue encore. Lit cette erreur, la corrige, relance.
5. Tout passe. Arrêt.

Personne n'a écrit ces étapes à l'avance. Le modèle a choisi chacune d'elles après avoir vu le résultat précédent.

C'est toute la différence. Cent étapes que vous avez écrites restent un workflow. Trois étapes choisies par le modèle forment une boucle.

N'utilisez une boucle que lorsque vous ne pouvez pas écrire les étapes à l'avance. Si vous pouvez les écrire, écrivez-les. Un workflow coûte moins cher, tourne en parallèle, et quand l'étape quatre plante, vous relancez l'étape quatre, pas tout le reste.

Les boucles coûtent aussi très cher. Un agent utilise environ quatre fois plus de tokens qu'un appel unique. Les configurations multi-agents tournent autour de quinze fois plus.

Comment la construire

Une boucle nécessite quatre éléments. Retirez-en un seul, et elle ne fonctionne plus :

1. Un objectif avec une condition de fin claire. Pas « corrige le bug ». Mais plutôt : « le test qui échoue dans auth_test.py passe, et rien d'autre n'est cassé. »
2. Un vérificateur. Quelque chose d'extérieur au modèle qui dit réussi ou échoué : une suite de tests, un compilateur, un linter. La recherche sur l'auto-correction est unanime sur ce point. Ça fonctionne avec un vrai retour externe, et ça échoue quand le modèle s'auto-évalue. Pas de vérificateur signifie pas de boucle, juste des dépenses sans fin.
3. Une règle d'arrêt. Le vérificateur valide, ou vous atteignez la limite de tours, ou les deux dernières tentatives ont donné le même résultat.
4. Un budget. En nombre de tours et en dollars. Les deux.

Dans le code, tout cela tient en quelques lignes :

1for turn in range(MAX_TURNS):
2    action = model.next_step(goal, history)
3    result = run(action)
4    history.append(result)
5
6    if checker(result):       break   # terminé
7    if repeated(history, 2):  break   # bloqué
8    if spent() > BUDGET:      break   # trop cher
9else:
10    fallback_workflow(goal)

La meilleure configuration en production que j'ai vue publiée est un hybride. Atlan applique d'abord un filtre déterministe, et seulement 14 % des alertes entrantes atteignent réellement l'agent.

La boucle dispose ensuite de trois cycles maximum. Si la confiance est toujours inférieure à 50 % après trois cycles, un workflow Python fixe prend le relais.

Filtrez d'abord, bouclez brièvement, prévoyez un plan B.

pic3. Comment choisir entre un workflow et une boucle

Le raccourci

Chaque tâche que vous confiez à Viktor dans un fil est une boucle. Vous écrivez l'objectif, il choisit les étapes, travaille à travers vos outils et revient dans le fil avec le résultat.

Les quatre éléments se traduisent ainsi :

• Objectif. Il recadre les briefs incomplets et pose des questions au lieu de deviner. Malgré tout, définissez le « terminé ». « Rapport de revenus de la semaine dernière, totaux alignés avec Stripe, publié dans #finance avant 9 h lundi » bat largement « fais le rapport ».
• Vérificateur. Il signale les chiffres qui semblent faux avant de publier. Renforcez-le en nommant la source de référence : le total Stripe, le nombre de lignes, la suite de tests.
• Règle d'arrêt. Les actions sensibles sont mises en pause pour validation humaine, et le résultat vous revient toujours.
• Budget. Des crédits. Le niveau de raisonnement définit le prix de chaque étape, et sur les tâches récurrentes, la fréquence compte énormément. Un rapport horaire coûte bien plus cher qu'un rapport hebdomadaire.

L'approche hybride d'Atlan fonctionne aussi sans code. Le travail répétitif devient une tâche planifiée : il la propose, et elle reste en pause jusqu'à votre validation. C'est votre workflow.

Tout ce qui est ouvert part dans un fil, et c'est votre boucle. Vous êtes le plan B.

3. Le Jev engineering

Définition

L'expert d'un bureau n'ouvre pas toutes les enveloppes. Quelqu'un à l'accueil trie le courrier : les factures dans une pile, le spam à la poubelle, les contrats à l'avocat.

Votre agent fait deux types de travail : rédiger quelque chose, et décider de quelque chose. Aujourd'hui, un seul gros modèle fait les deux, ce qui revient à payer l'avocat pour trier le courrier.

Jev, c'est l'accueil. Il ne rédige jamais. Il choisit uniquement.

Comment ça marche

Vous donnez à Jev une question et les réponses possibles à l'avance. Il renvoie l'une de ces trois choses, accompagnée d'un score de confiance :

• oui ou non
• une option parmi un ensemble
• un chiffre sur une échelle

Comme il ne fait que choisir, il est rapide et peu coûteux. Les chiffres annoncés sont de 70 à 500 millisecondes contre 3 à 329 secondes, et 0,042 $ par million de tokens en entrée, avec la sortie gratuite.

Maintenant, soyons honnêtes. Jev a deux semaines d'existence et les tests indépendants commencent tout juste à arriver.

• Sur la classification d'e-mails, une simple régression logistique a atteint 98,9 % contre 98,6 % pour Jev.
• Sur la détection de phishing, Jev a obtenu 62,6 % tandis que Claude Haiku 4.5 atteignait 81,3 %.
• Le chiffre de « zéro hallucination » s'accompagne de la propre note de bas de page des auteurs : ce n'est pas empirique, cela signifie simplement que la sortie correspond toujours au schéma.

Le score de confiance n'est pas non plus une vraie probabilité telle quelle. Considérez-le comme un classement et définissez vos propres seuils sur vos données étiquetées.

Comment le construire

La configuration logique est une barrière placée devant le modèle coûteux :

1. Tout arrive.
2. Jev répond à une question très précise sur chaque élément.
3. Confiant et routinier : traité à moindre coût. Étiqueté, routé ou jeté.
4. Incertain ou inhabituel : envoyé au modèle principal.

1d = jev.choose(item, options=["spam", "order_status", "refund", "other"])
2
3if d.confidence >= 0.7 and d.option != "other":
4    handle_cheap(d.option, item)
5else:
6    main_model(item)   # fail closed : l'incertitude part vers le chemin coûteux

Avant tout cela, essayez la solution la plus bête qui pourrait fonctionner. Étiquetez quelques centaines d'exemples réels, entraînez un classificateur basique, et ne montez en gamme que si ce n'est pas suffisant.

C'est trente minutes de travail, et c'est la référence que toute promesse commerciale doit battre.

pic4. Les trois types de questions auxquelles Jev répond

Le raccourci

Jev ne fait pas partie de la stack officielle de Viktor, mais l'idée s'applique à deux endroits que vous contrôlez :

• Le niveau de raisonnement. Il en utilise trois : Smart sur Claude Opus, Balanced sur Claude Sonnet pour environ la moitié du prix, et Ultra sur Claude Fable pour environ le double. Trier des requêtes ou extraire un chiffre ne nécessite pas le niveau supérieur.
• La barrière devant lui. Si vous voulez qu'il gère un flux comme des e-mails de support ou des alertes, ne lui donnez pas tout le flux. Placez d'abord un classificateur ou un appel Jev, pour que seuls les éléments nécessitant un jugement deviennent des tâches pour lui.

C'est l'une des deux couches où votre propre ingénierie compte encore, même avec Viktor.

4. Le harness engineering

Définition

Même collaborateur, deux bureaux. Dans le premier, il a les bons outils, un manuel affiché au mur, un collègue qui vérifie son travail, et aucune clé du coffre-fort. Dans le second, il a un ordinateur portable et votre mot de passe administrateur.

Mêmes compétences, résultats radicalement différents. Le collaborateur est le modèle. Le bureau est le harness.

Agent = modèle + harness.

Comment ça marche

Le harness, c'est tout ce qui n'est pas le modèle : les outils, les permissions, le bac à sable, les fichiers qui expliquent le projet, les contrôles sur la sortie.

C'est devenu une discipline à part entière en 2026 parce que les gens ont commencé à mesurer, et que le modèle expliquait moins de choses que prévu :

• Anthropic n'a modifié que les ressources du conteneur et a fait bondir un score de benchmark de 6 points.
• LangChain a figé le modèle et a fait progresser le même benchmark de 13,7 points en ne changeant que le harness.
• Ensuite, ils ont optimisé le harness autour d'un modèle open source dix fois moins cher jusqu'à obtenir 0,86 contre 0,87 pour Opus 4.8.

Vous n'achetez plus un modèle. Vous achetez un modèle et un harness ensemble.

Vous en avez besoin dès l'instant où l'agent touche à quelque chose de réel : un repo, une boîte de réception, un paiement, une base de données de production.

Comment le construire

Construisez de l'extérieur vers l'intérieur :

1. Le confinement. Ce que l'agent ne peut physiquement pas atteindre. Un conteneur, une branche séparée, un utilisateur de base de données en lecture seule, aucun réseau hormis une liste blanche. Faites-le avant le premier prompt.
2. Les guides. Ce qui l'oriente avant qu'il n'agisse. Un fichier dans le repo comme AGENTS.md, des descriptions d'outils assez claires pour que le modèle choisisse le bon, quelques exemples de bonnes sorties.
3. Les capteurs. Ce qui le contrôle après son action. Linter, vérificateur de types, suite de tests : rapides et déterministes, donc lancez-les sur tout. Les contrôles plus lents, comme un second modèle qui révise un diff, uniquement sur ce qui compte.
4. Les permissions. Quand les agents demandent une approbation, les humains valident 93 % du temps. L'invite d'approbation ne protège presque rien. La vraie protection, ce sont les actions qui sont tout simplement indisponibles. Réservez l'approbation aux rares choses véritablement irréversibles.

Un fichier guide n'a pas besoin d'être long. Quatre lignes changent déjà le comportement :

1# AGENTS.md
2- Monorepo : /api (FastAPI), /web (Next.js), /jobs (cron)
3- Lance les tests avec `make test`. Ils doivent passer avant tout commit
4- Ne jamais modifier /migrations à la main, utiliser `make migration`
5- L'accès à la DB est en lecture seule. Demander avant tout changement de schéma

Les hooks sont la version stricte de cette même idée. Dans Claude Code, un hook est un petit script qui s'exécute avant l'appel d'un outil et peut le bloquer. « Ne jamais pousser sur main » fonctionne comme un hook, pas comme une ligne dans le prompt.

Un avertissement. Chaque élément de votre harness est un pari sur l'incapacité du modèle à faire quelque chose, et ces paris ont une date d'expiration. Anthropic a supprimé tout un composant d'échafaudage après qu'une mise à jour du modèle l'a rendu inutile.

Relisez votre harness tous les quelques mois et supprimez ce dont le modèle n'a plus besoin.

pic5. Les quatre anneaux d'un harness

Le raccourci

Si agent = modèle + harness, la majeure partie de ce que vous obtenez avec Viktor est du harness. Le modèle en dessous est Claude. Tout ce qui entoure le modèle est prêt à l'emploi :

• Outils. Plus de 3 200 intégrations : GitHub, Linear, HubSpot, Stripe, Notion, Google Drive et bien d'autres. Pour un outil sans connexion prête à l'emploi, il peut en créer une lui-même.
• Guides. Les skills. Au lieu de rédiger AGENTS.md vous-même, vous enregistrez votre écran, il rédige la procédure, vous la modifiez.
• Capteurs. Il signale les données incohérentes et remet en question les briefs incomplets. Et chaque étape atterrit dans un fil Slack que votre équipe peut lire.
• Permissions. Les e-mails clients et les modifications financières sont mis en pause pour approbation. Les nouvelles automatisations planifiées restent en pause jusqu'à ce que quelqu'un les active.

La seule partie qu'aucun produit ne peut construire à votre place est le confinement, car il dépend des identifiants que vous fournissez. Rappelez-vous les 93 %, et connectez-le avec le minimum d'accès nécessaire au travail :

• un utilisateur de base de données en lecture seule
• une clé Stripe restreinte
• une boîte de réception support partagée, et non la vôtre personnellement
• un token GitHub limité à des repos spécifiques

Ce qu'il ne peut pas atteindre, il ne peut pas le casser.

pic6. Le harness de Viktor

5. L'evals engineering

Définition

Comment savez-vous qu'une nouvelle recrue s'est améliorée ? Vous lui faites passer le même test que le mois dernier et vous comparez.

Sans le même test, chaque changement que vous faites est une supposition. Les evals sont ce test pour votre agent : un ensemble de tâches dont vous connaissez déjà la bonne réponse, exécuté à chaque modification.

Comment ça marche

Il existe deux types de contrôles :

• End to end (de bout en bout). La réponse finale est-elle correcte ? Cela vous indique que le score a bougé, mais pas pourquoi.
• Behavioral (comportemental). Une action précise s'est-elle produite ? A-t-il appelé la recherche avant de répondre ? A-t-il posé une question de clarification quand la requête était floue ? A-t-il vérifié avant de dire « terminé » ?

Les contrôles comportementaux s'exécutent sur la trace, le journal de tout ce que l'agent a fait, et pas seulement sur la réponse finale. La règle de Google est que cette suite doit s'exécuter en moins de cinq secondes, afin de pouvoir tourner à chaque modification.

Si un modèle assure la notation, c'est un juge, et ce juge doit lui aussi être contrôlé. Airbnb a découvert qu'environ trois quarts de leurs réponses de référence générées par modèle variaient lors d'exécutions répétées sur la même entrée. Leur eval mesurait son propre bruit.

Comment le construire

1. Partez des vrais échecs. Parcourez les exécutions réelles, trouvez ce qui a mal tourné, transformez chaque cas en scénario de test. Les golden sets d'Airbnb comportent 50 à 100 exemples, et les échecs y sont obligatoires.
2. Écrivez un contrôle comportemental par cas. Un cas, une chose à vérifier.
3. Testez votre juge. Notez un échantillon à la main et voyez à quelle fréquence vous et le modèle êtes d'accord avant de lui faire confiance.
4. Échantillonnez la production. Airbnb extrait 5 % du trafic en direct chaque jour. Votre jeu d'evals s'use à mesure que l'utilisation réelle s'en éloigne.

Un cas unique peut être aussi court que ceci :

1input: "Rembourser la commande #1042, le client dit qu'elle est arrivée cassée"
2expect:
3  - recherche la commande avant de répondre
4  - demande une approbation avant d'émettre le remboursement
5check:
6  - la trace contient get_order avant send_reply
7  - la trace contient approval_request avant refund

Ne surveillez pas le taux de réussite global. Il peut augmenter pendant qu'un comportement spécifique se casse silencieusement. Surveillez les contrôles individuels.

pic7. D'où viennent les bons cas d'evals

Le raccourci

Aucun produit ne peut livrer cette couche à votre place, car vous seul savez à quoi ressemble la bonne réponse pour votre entreprise. La méthode se transpose toutefois directement :

• Après deux semaines, sélectionnez 20 de ses fils dont vous connaissez la bonne réponse. Incluez tous ceux où vous avez dû le corriger.
• Écrivez un contrôle simple par cas. A-t-il lié une source pour chaque chiffre, a-t-il posé une question quand le brief était flou, s'est-il mis en pause avant que quoi que ce sorte de l'entreprise ?
• Relancez le jeu après chaque changement : une nouvelle skill, un brief modifié, un niveau différent. Passer de Smart à Balanced économise environ la moitié des crédits, alors testez avant de basculer définitivement.
• Une fois par semaine, notez cinq fils aléatoires à la main.

Assembler le tout

Cinq couches, cinq questions. Le contexte, c'est ce qu'il voit. La boucle, c'est qui décide. Jev gère les décisions bon marché. Le harness, c'est ce qu'il peut atteindre et qui le contrôle. Les evals, c'est comment vous le savez.

Avec Viktor, trois d'entre elles sont quasiment intégrées : le contexte, la boucle et le harness. Jev, les evals et les identifiants que vous fournissez relèvent de votre propre ingénierie.

Si vous débutez aujourd'hui, voici l'action utile la moins chère pour chacune :

• Contexte : déplacez vos instructions stables dans le system prompt et arrêtez de les modifier.
• Boucle : fixez-lui une limite de tours et une limite de dollars avant de la laisser tourner.
• Jev : étiquetez 200 exemples de ce que votre agent décide le plus souvent.
• Harness : exécutez votre agent en tant qu'utilisateur incapable de supprimer quoi que ce soit.
• Evals : notez vos cinq derniers échecs sous forme de cas de test.

Sur Viktor, cette même journée ressemble à ceci :

• Contexte : rédigez la fiche entreprise et enregistrez votre première skill.
• Boucle : incluez une définition de « terminé » dans chaque tâche et choisissez le niveau de raisonnement en connaissance de cause.
• Jev : filtrez tout flux avant qu'il ne se transforme en tâches pour lui.
• Harness : connectez-le avec des identifiants en lecture seule et limités.
• Evals : sauvegardez 20 fils réels comme premier jeu de test.

C'est une journée de travail, et cela couvre les cinq couches.

Mon avis : le modèle n'est plus la partie difficile. Ce sont les cinq couches autour de lui qui le sont. Maîtrisez-les et vous augmenterez votre capacité sans recruter. La plupart des équipes devraient prendre les trois premières sur étagère et consacrer leur temps aux deux qui déterminent la qualité : les décisions bon marché et les evals.

Merci à Viktor d'avoir sponsorisé cet article.

Essayez gratuitement sur @viktor_com. 100 $ de crédits, sans carte bancaire. Lien complet dans ma première réponse.

Utilisez le code YARCHI100 lors de votre inscription.

Partenariat rémunéré