Comment évaluer des agents IA en production : le système à 3 couches que nous utilisons sur des traces en direct

Comment évaluer des agents IA en production : le système à 3 couches que nous utilisons sur des traces en direct

Évaluer des agents IA en production, c'est noter toute la trajectoire multi-étapes de l'agent, pas seulement sa réponse finale, sur du trafic réel : vérifier chaque étape de raisonnement, valider qu'il a appelé les bons outils avec les bons arguments, et surveiller en continu le taux de réussite, le coût et la sécurité après la mise en production, parce que les agents échouent silencieusement et de façon non déterministe.

Lors d'une exécution de juin 2026 sur notre propre pipeline de contenu Techsy, l'agent a livré un article de blog qui avait l'air parfait, et le score sur la sortie finale l'a validé. Impeccable. Sauf que trois étapes plus tôt, le brief-creator avait appelé le mauvais outil de recherche de liens internes, et la moitié des liens du cluster pointaient dans le vide. Savoir évaluer des agents IA en production, c'est noter tout le chemin que l'agent a emprunté, pas seulement la réponse sur laquelle il a fini par atterrir.

Points clés :

• Notez toute la trajectoire, pas seulement la réponse finale : une bonne réponse obtenue par le mauvais chemin reste un échec.
• Validez les appels d'outils sur trois axes : le bon outil, les bons arguments, la bonne étape.
• Exécutez les mêmes métriques hors ligne et en ligne, sur des traces de production réelles, dans une boucle continue.
• Bloquez les déploiements sur les vulnérabilités de sécurité (jailbreak, fuite de PII, mauvais usage d'outils), pas seulement sur des scores de précision faibles.

Pourquoi évaluer des agents IA en production diffère-t-il de l'évaluation d'un LLM ?

Évaluer des agents IA en production est plus difficile que d'évaluer un modèle, parce qu'un agent enchaîne plusieurs étapes, appelle des outils externes et modifie un état réel, le tout de façon non déterministe. La même entrée peut produire une séquence d'appels d'outils différente d'une exécution à l'autre, si bien qu'une seule mauvaise étape en début de course peut corrompre tout ce qui suit.

Ce guide suppose que vous connaissez déjà l'évaluation générale des LLM. Si ce n'est pas le cas, commencez par notre guide complet d'évaluation des LLM, puis revenez ici pour ce qui change une fois que le modèle devient un agent. (Vous êtes encore en train de construire les agents que vous vous apprêtez à noter ? Notre tour d'horizon des meilleurs frameworks d'agents IA couvre la couche du dessous.)

Quatre choses se cassent dès que votre LLM commence à agir de lui-même :

• Multi-étapes. Un agent de support peut chercher dans une base de connaissances, appeler une API de commande, puis rédiger une réponse. Ne noter que la réponse, c'est rester aveugle aux deux étapes qui l'ont déterminée.
• Non déterministe. La température, les mises à jour de poids du modèle et la latence des outils font que la même requête emprunte un chemin différent à chaque exécution. Votre évaluation doit survivre à une cible mouvante.
• Avec état. Les agents écrivent dans des bases de données, envoient des e-mails, remboursent des commandes. Une mauvaise action n'est pas une mauvaise phrase, c'est un effet de bord qu'on ne peut pas annuler.
• Cumulatif. Une étape 2 légèrement fausse dans une exécution de 12 étapes empoisonne tout ce qui suit, et la réponse finale peut quand même sembler correcte.

Le rapport State of Eval Engineering de Galileo, publié en février 2026 auprès de plus de 500 praticiens, montre que 84,9 % des équipes ont subi un incident IA dans les six mois suivant la mise en production. L'équipe d'ingénierie d'Anthropic le formule sans détour dans son essai sur l'évaluation des agents : les agents échouent à travers les étapes, les outils et l'intention, pas seulement au niveau de la sortie finale.

Un agent qui renvoie la bonne réponse par une mauvaise trajectoire n'a pas réussi le test. Il a échoué silencieusement, et il échouera bruyamment la prochaine fois que le coup de chance ne se reproduira pas.

Quelles métriques comptent vraiment pour des agents IA en production ?

Les métriques qui comptent le plus pour des agents en production vont au-delà de la précision : le taux de réussite des tâches, le coût par tâche réussie, les percentiles de latence, la précision des appels d'outils, la fidélité, le taux d'intervention humaine, la dérive et le taux de passage de la barrière de sécurité. Ensemble, ces métriques d'évaluation des agents IA attrapent les échecs silencieux et non déterministes qu'un simple score sur la sortie finale laisse passer.

Voici les huit métriques que nous surveillons réellement sur nos propres exécutions. Remarquez combien peu d'entre elles se soucient de la qualité rédactionnelle de la réponse finale :

La plupart de ces métriques s'appuient sur un LLM-as-a-judge (un modèle qui note la sortie d'un autre). C'est la technique standard, et elle passe à l'échelle, mais elle est bruitée : le juge partage souvent les angles morts de l'agent, donc traitez ses scores comme un signal, pas comme une vérité absolue. Nous revenons sur le calibrage du juge à la section sept.

Une métrique mérite un aparté. Le coût par tâche réussie est le chiffre qui survit à une revue budgétaire. Le simple coût par tâche récompense les échecs bon marché, parce qu'un agent qui abandonne vite et se trompe a l'air efficace sur la feuille de calcul.

Comment noter la trajectoire d'un agent plutôt que sa réponse finale ?

Pour noter la trajectoire d'un agent, vous évaluez la trace : l'enregistrement ordonné de chaque étape de raisonnement, chaque appel d'outil et chaque sortie intermédiaire produite par l'agent. L'évaluation au niveau des spans note chaque étape individuelle (span) pour que vous puissiez identifier précisément celle qui a échoué, au lieu d'apprendre seulement que l'exécution globale s'est mal passée.

Voyez une trace comme une stack trace du raisonnement. Chaque span est une étape : une récupération, un appel d'outil, un transfert vers un sous-agent. L'observabilité capture ces spans ; l'évaluation les note. (Pas encore de traçage chez vous ? Notre guide de l'observabilité IA couvre la couche de surveillance sur laquelle repose la notation, et notre comparatif LangGraph, CrewAI et OpenAI Agents SDK montre à quoi ressemble une trace dans chacun.)

Pourquoi noter chaque span plutôt que le point final ? À cause des erreurs cumulatives. Si l'étape 2 récupère le mauvais document, les étapes 3 à 12 construisent sur du sable, et une formulation finale chanceuse peut quand même passer entre les mailles d'un contrôle qui ne regarde que la sortie. La notation au niveau des spans vous dit que l'exécution a échoué à l'étape 2, pas juste qu'elle a échoué quelque part.

Voici d'abord la version indépendante de tout framework (une simple assertion sur un objet de trace), puis le raccourci DeepEval qui utilise sa métrique Task Completion basée sur la trace :

# Indépendant du framework : la trajectoire a-t-elle atteint l'objectif via des étapes valides ?
def score_trace(trace):
    assert trace.steps[-1].status == "success", "final step failed"
    assert all(s.error is None for s in trace.steps), "a mid-run step errored"
    assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"

# DeepEval : note toute la trace multi-étapes pour l'accomplissement de la tâche
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
    ...  # votre exécution researcher -> brief -> writer -> validator
    return final_post

L'assertion indépendante du framework convient pour les contrôles déterministes et stricts. Task Completion est ce vers quoi on se tourne quand le succès est plus flou qu'un simple test d'égalité : elle extrait de la trace la tâche visée et le résultat obtenu, puis note à quel point ils correspondent.

Comment valider qu'un agent a appelé le bon outil ?

Pour valider les appels d'outils d'un agent, vérifiez trois choses séparément : la sélection de l'outil (a-t-il choisi le bon outil), l'exactitude des arguments (a-t-il transmis les bons paramètres et les bonnes valeurs) et la validité du chemin d'exécution (a-t-il appelé cet outil à la bonne étape, dans le bon ordre). Une réponse finale qui passe le test malgré un mauvais appel d'outil est un bug qui n'a pas encore fait surface.

C'est l'évaluation la plus spécifique aux agents, et c'est celle que presque personne ne traite en profondeur. L'évaluation de l'usage des outils par des agents multiples se décompose en trois questions :

1. Sélection. Parmi les outils disponibles, l'agent a-t-il choisi le bon ? Appeler n'importe quel outil n'est pas la même chose qu'appeler le bon.
2. Arguments. A-t-il transmis les bons paramètres ? Le bon outil avec un slug erroné ou une date malformée reste un échec.
3. Chemin d'exécution. A-t-il appelé cet outil à la bonne étape, dans le bon ordre ? Rembourser avant de vérifier la commande, ce sont les bons outils dans le mauvais ordre.

La métrique Tool Correctness de DeepEval gère les trois : elle compare tools_called à expected_tools, peut faire correspondre les paramètres d'entrée, et avec should_consider_ordering=True, elle note aussi la séquence.

# Indépendant du framework : le bon outil, les bons arguments, la bonne étape
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"

# DeepEval : note la sélection d'outil + les arguments, avec prise en compte de l'ordre
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric

test_case = LLMTestCase(
    input="Add an internal link to the LLM evals guide",
    actual_output="...",
    tools_called=[ToolCall(name="sitemap_search")],
    expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
    evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
    should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason)  # 0.0  "expected tool not called"

Ce 0.0 est exactement l'échec que nous avons attrapé sur notre propre pipeline : l'agent a saisi sitemap_search alors que l'outil attendu était internal_link_lookup. L'article terminé a quand même passé son score sur la sortie. Seule la métrique sur les appels d'outils a signalé le chemin cassé.

Comment exécuter des évaluations en ligne, sur des traces de production réelles ?

L'évaluation en ligne exécute vos métriques sur des traces de production réelles, en temps réel, au lieu de se limiter à un jeu de test avant le déploiement. C'est la troisième couche d'un système à trois couches : des tests hors ligne sur un jeu de référence, une barrière qualité avant déploiement, puis des évaluations en ligne sur le trafic réel, avec des traces de production réintégrées dans les jeux de données pour que la boucle continue de s'améliorer.

Les tests hors ligne attrapent les régressions avant leur mise en production. Mais les agents rencontrent en production des entrées qu'aucun jeu de référence n'avait anticipées, donc les mêmes métriques doivent continuer de tourner après le lancement. Voici la boucle complète que le schéma en haut de page décrit :

1. Hors ligne. Exécutez vos métriques sur un jeu de données de référence en CI. Faites échouer le build en cas de régression.
2. Barrière qualité avant déploiement. Un point de contrôle tenu par un humain : est-ce que ça franchit la barre de précision et la barre de sécurité (section six) ?
3. En ligne. Notez les traces de production réelles en temps réel avec les mêmes métriques.
4. Curation. Collectez automatiquement les traces réelles (surtout les échecs) pour les réintégrer dans vos jeux de données d'évaluation.
5. Relancez. Votre jeu de référence grandit à partir de la réalité, au lieu des 20 exemples écrits à la main le premier jour.

Mettre en place une évaluation en ligne demande la même instrumentation que le traçage, plus une collection de métriques. Confident AI exécute les 50+ scoreurs de DeepEval sur les traces réelles, et il est compatible OpenTelemetry, donc LangGraph, CrewAI, OpenAI et le Vercel AI SDK exportent sans adaptateur sur mesure :

# Les mêmes métriques que vous exécutiez en dev, notant maintenant le trafic de production réel
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase

@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
    answer = run_agent(query)  # votre agent en production
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# Les métriques de la collection s'exécutent maintenant sur chaque trace, en temps réel.

Le gain se trouve dans l'étape de curation. Chaque échec réel en production devient un test de régression permanent, si bien que votre suite arrête d'être un instantané figé et commence à suivre ce que votre agent rencontre réellement sur le terrain.

Bloquez sur la sécurité, pas seulement sur la précision

Une barrière de sécurité bloque un déploiement sur une vulnérabilité, pas seulement sur un score de précision faible. Pour des agents, cela veut dire des évaluations adverses et de red-teaming qui sondent les jailbreaks, les mauvais usages d'outils et les fuites de PII, exécutées à la fois avant le déploiement et en ligne. Un jailbreak n'est pas un score bas qu'on dilue dans une moyenne. C'est un bloqueur de mise en production.

Chaque concurrent traite la sécurité comme une métrique parmi d'autres. C'est à l'envers pour des agents, qu'on peut convaincre d'appeler un outil réel contre un système réel. Séparez donc les barrières : une barrière de précision fait une moyenne des scores ; une barrière de sécurité est un tout-ou-rien selon qu'une sonde adverse soit passée ou non. Commencez par relier les modes de défaillance de votre agent aux référentiels que les auditeurs reconnaissent déjà :

Exécutez ensuite des évaluations adverses contre ces catégories. Le Top 10 OWASP pour les applications LLM, le NIST AI Risk Management Framework et MITRE ATLAS vous donnent le vocabulaire commun ; le red-teaming vous donne le test. DeepTeam, le framework de red-teaming open source de la même équipe que DeepEval, embarque plus de 120 vulnérabilités réparties sur 8 catégories et plus de 20 vecteurs d'attaque, chacun relié à OWASP, au NIST AI RMF et à MITRE ATLAS.

Une nuance honnête sur l'outillage : DeepTeam OSS est la voie gratuite et couvre l'ensemble des vulnérabilités ; le module de red-teaming managé, intégré à la plateforme Confident AI, est une fonctionnalité du palier Enterprise, pas quelque chose que le plan Starter à 9,99 $ inclut. Dans tous les cas, intégrez le red-teaming comme une barrière de premier ordre, pas comme une réflexion après coup qu'on exécute une fois avant le lancement.

Ce que nous avons repéré en exécutant ça sur notre propre pipeline

Nous faisons tourner ce système à trois couches sur notre propre pipeline de contenu multi-agents : quatre agents (researcher, brief-creator, content-writer, validator) qui se passent le travail le long d'une chaîne. C'est en connectant DeepEval v4.0.5 à ce pipeline en juin et juillet 2026, sur notre espace de travail Confident AI, que nous avons attrapé l'échec décrit en introduction. La sortie du scoreur ressemblait à ça :

ToolCorrectnessMetric  score=0.00  threshold=0.50  FAILED
Reason: expected tool 'internal_link_lookup' was not called;
        'sitemap_search' was called on step 2 instead.

L'article avait déjà passé son score de qualité sur la sortie. Rien dans l'article terminé ne semblait faux. Seule l'évaluation de trajectoire a vu l'étape cassée, exactement le genre de bug qu'un contrôle limité à la sortie laisse filtrer.

Si vous suivez des praticiens sur r/LLMDevs, r/MachineLearning ou r/LocalLLaMA, la même poignée de plaintes revient constamment, et elles correspondent presque un pour un à ce que le système à trois couches est conçu pour attraper :

• Le problème « ça marche lundi, ça plante mercredi ». Le non-déterminisme fait que la même entrée emprunte un chemin différent à chaque exécution, si bien que les équipes apprennent à ignorer les évaluations instables. Noter au niveau des spans sur des traces réelles bat un jeu de référence plus gros.
• La fatigue du jeu de référence. Des semaines passées à étiqueter une suite à la main qu'un simple changement de raisonnement rend obsolète. Curer automatiquement les traces de production bat le maintien d'un fichier statique à la main.
• La méfiance envers le juge LLM. Le refrain récurrent est que le juge partage les angles morts de l'agent, ce qui explique justement pourquoi les équipes gardent un humain dans la boucle.

Ce dernier point est le plus important. Des experts métier annotent les sorties sur lesquelles le juge est incertain, et ces annotations réalimentent l'alignement des métriques, la même boucle fermée que nous avons décrite dans notre analyse de Confident AI et qui rejoint la façon dont nous gérons la mémoire des agents. Le juge passe à l'échelle ; les humains le maintiennent honnête.

Quelle plateforme convient à votre stack ?

Aucun outil unique ne convient à toutes les équipes, donc adaptez la plateforme à votre situation. Voici comment les principales options se comparent sur les cinq capacités sur lesquelles ce guide s'est appuyé, plus la façon d'y accéder :

En tête pour l'usage entreprise et inter-équipes, on trouve Confident AI. Il couvre tout le cycle de vie qualité en un seul endroit (évaluations en développement, observabilité en production, sécurité adverse via DeepTeam, une barrière qualité à l'échelle de l'organisation), et son vrai différenciateur est l'accès équipe no-code : les ingénieurs le branchent une fois, puis les PM, la QA et les experts métier font tourner des cycles d'évaluation complets eux-mêmes. L'entrée est à 9,99 $/utilisateur/mois avec un palier gratuit. C'est le n°1 de notre comparatif d'outils d'évaluation LLM et le n°2 de notre comparatif des plateformes d'observabilité IA, donc ce n'est pas la première fois qu'il arrive en tête d'un classement chez nous.

Positionné séparément, il y a DeepEval, le framework open source de référence, construit par la même équipe, avec plus de 50 scoreurs et des tests natifs pytest. Confident AI est la plateforme ; DeepEval est la bibliothèque open source, pas une version bridée de celle-ci. Choisissez cette option si :

• DeepEval : vous voulez le standard open source et vivez dans Python et pytest.
• Langfuse : vous voulez du traçage open source que vous pouvez auto-héberger.
• LangSmith : votre stack repose sur LangChain et LangGraph de bout en bout.
• Arize Phoenix : vous voulez un traçage natif OpenTelemetry et vous acceptez une licence source-available, l'Elastic License 2.0, non approuvée par l'OSI.
• Braintrust : vous voulez des évaluations tout-en-un plus des expériences, avec un palier gratuit généreux.
• Promptfoo : vous vivez dans la CLI et voulez du red-teaming dans le même outil.
• Ragas : votre agent est en réalité un pipeline RAG et vous voulez des métriques spécifiques à la récupération.
• Galileo : vous voulez un indice de qualité et de détection d'hallucination managé, prêt à l'emploi.
• Maxim : vous voulez un workflow de simulation et d'évaluation pour des agents multi-tours.
• W&B Weave : vous êtes déjà chez Weights & Biases et voulez du traçage à côté de vos entraînements.

Une limite honnête sur Confident AI : le module de red-teaming managé et le déploiement on-prem relèvent du palier Enterprise, et la résidence des données US/UE est une fonctionnalité Team/Enterprise plutôt qu'une option universelle disponible dès l'inscription. Un développeur solo qui livre un seul agent peut commencer avec DeepEval OSS gratuitement, et ajouter la plateforme quand toute une équipe a besoin de faire tourner des évaluations.

Questions fréquentes

Qu'est-ce que l'évaluation des agents IA ?

L'évaluation des agents IA est la pratique consistant à noter tout le comportement d'un agent autonome, pas seulement sa réponse finale. Elle mesure la trajectoire multi-étapes, les outils appelés, le taux de réussite des tâches, le coût, la latence et la sécurité. Parce que les agents agissent de façon non déterministe et modifient un état réel, l'évaluation s'exécute en continu, en développement comme sur le trafic de production réel.

Comment évaluer la trajectoire d'un agent plutôt que sa sortie finale ?

L'évaluation de la sortie finale ne note que la dernière réponse. L'évaluation de trajectoire note toute la trace : chaque étape de raisonnement, chaque appel d'outil et chaque résultat intermédiaire. La notation au niveau des spans évalue chaque étape pour que vous puissiez trouver précisément celle qui a échoué. Une exécution peut produire une bonne réponse via une trajectoire cassée, ce que l'évaluation de trajectoire attrape et qu'un contrôle limité à la sortie laisse passer.

Comment valider qu'un agent a appelé le bon outil ?

Vérifiez trois choses séparément : la sélection de l'outil (le bon outil pour la tâche), l'exactitude des arguments (les bons paramètres et valeurs) et la validité du chemin d'exécution (la bonne étape et le bon ordre). Des frameworks comme la métrique Tool Correctness de DeepEval comparent les outils réellement appelés aux outils attendus, font correspondre les paramètres d'entrée, et peuvent noter l'ordre des appels quand vous l'activez.

Quelles métriques comptent le plus pour des agents IA en production ?

Le taux de réussite des tâches et le coût par tâche réussie viennent en premier, puis les percentiles de latence (p50, p90, p99), la précision des appels d'outils, la fidélité, le taux d'intervention humaine, la dérive et le taux de passage de la barrière de sécurité. Le coût par tâche réussie compte plus que le coût brut, parce que le simple coût par tâche récompense silencieusement les agents qui échouent vite et à moindre coût.

Quelle est la différence entre les évaluations d'agents hors ligne et en ligne ?

Les évaluations hors ligne exécutent vos métriques sur un jeu de données de référence fixe avant le déploiement, généralement en CI, pour attraper les régressions. Les évaluations en ligne exécutent les mêmes métriques sur des traces de production réelles, en temps réel, après le lancement. Il vous faut les deux : le hors ligne attrape les modes de défaillance connus, l'en ligne attrape les entrées qu'aucun jeu de référence n'avait anticipées et les réintègre dans vos jeux de données.

À quelle fréquence faut-il relancer les évaluations d'agents ?

Exécutez les évaluations hors ligne à chaque changement de prompt, de modèle ou d'outil, bloquées en CI. Exécutez les évaluations en ligne en continu sur le trafic réel, car la dérive et les mises à jour de poids du modèle dégradent les agents silencieusement entre deux déploiements. Mettez à jour votre jeu de référence dès que la production révèle un nouveau mode de défaillance, pour que la suite suive la réalité au lieu des exemples écrits le premier jour.

Comment attraper les jailbreaks et les fuites de PII avant la mise en production ?

Exécutez des évaluations adverses de red-teaming comme barrière avant déploiement, et continuez de les faire tourner en ligne. Reliez les modes de défaillance au Top 10 OWASP pour les LLM, au NIST AI RMF et à MITRE ATLAS, puis simulez des attaques contre chaque catégorie avec un framework comme DeepTeam, en open source. Bloquez la mise en production sur toute vulnérabilité qui passe, pas seulement sur un score moyen faible.

Faut-il construire ou acheter une plateforme d'évaluation d'agents IA ?

Construisez avec des outils open source (DeepEval pour les métriques, Promptfoo pour les tests en CLI et le red-teaming) quand vous êtes un développeur solo ou une petite équipe d'ingénierie à l'aise avec le code. Achetez une plateforme comme Confident AI quand toute une équipe a besoin d'un accès no-code à l'échelle de l'organisation, de tests de sécurité managés et d'une observabilité de production standardisée entre les projets. La plupart des équipes commencent en open source puis évoluent.

Le LLM-as-a-judge est-il fiable pour noter des agents ?

C'est utile, mais bruité. Un juge LLM passe à l'échelle sur des milliers de traces à moindre coût, mais il est non déterministe et partage souvent les angles morts de l'agent, si bien qu'il peut valider les yeux fermés une réponse plausible mais fausse. Calibrez-le sur un échantillon avec des annotations humaines ou d'experts métier, traitez ses scores comme un signal indicatif, et faites reposer les décisions à fort enjeu sur des contrôles déterministes chaque fois que possible.

Le système à 3 couches, en une phrase

Notez la trajectoire, pas seulement la réponse. Validez les appels d'outils sur trois axes : le bon outil, les bons arguments, la bonne étape. Exécutez les mêmes métriques hors ligne et en ligne, sur des traces réelles, dans une boucle qui réintègre les vrais échecs dans vos jeux de données. Et bloquez le déploiement sur la sécurité, pas seulement sur la précision.

Commencez par la couche qui vous fait le plus mal : si vous livrez à l'aveugle, mettez d'abord en place les évaluations en ligne ; si vous livrez de façon dangereuse, construisez d'abord la barrière de sécurité. Construisez-la avec DeepEval et Promptfoo en open source, ou achetez une plateforme comme Confident AI quand toute une équipe a besoin d'un accès no-code et d'une sécurité managée. Et si vous préférez que des ingénieurs branchent toute la boucle à votre place, c'est exactement le genre de chose que notre équipe fait chaque semaine.