Evidently : évaluer et surveiller un système ML ou LLM sans quitter Python

Deux problèmes que le même objet Report recouvre

Evidently répond à deux besoins qui, dans beaucoup de projets, finissent dans deux outils séparés. Le premier est l'évaluation ponctuelle : on dispose d'un jeu de données, on veut savoir si les distributions ont bougé, si un modèle se dégrade, ou si des réponses générées tiennent la route. Le second est la surveillance dans le temps : on veut voir ces mêmes mesures évoluer entre plusieurs exécutions. Le README présente la bibliothèque comme un cadre pour « evaluate, test and monitor ML and LLM systems », et la structure de l'API reflète cette double vocation : un objet Report produit le calcul, et ce même objet alimente soit une sortie de notebook, soit un service d'interface. Le public visé est donc l'équipe qui fait déjà tourner Python sur ses données : data scientists, ingénieurs ML, et depuis peu les équipes qui construisent des applications à base de modèles de langage. Le notebook Jupyter étant le langage principal du dépôt, l'usage exploratoire est clairement le point d'entrée prévu.

Descriptors, presets et le trajet d'une donnée jusqu'au rapport

Le mécanisme visible dans le README tient en trois couches. À la base, la donnée est encapsulée dans un objet Dataset construit par Dataset.from_pandas, avec un DataDefinition qui décrit le schéma. Sur cet objet on greffe des descriptors, qui sont des évaluateurs au niveau de la ligne : Sentiment("answer", alias="Sentiment") ajoute une colonne de score, TextLength en ajoute une autre, Contains("answer", items=['sorry', 'apologize'], mode="any", alias="Denials") marque les réponses qui contiennent un mot de la liste. Le README donne cet exemple précis et indique que eval_dataset.as_dataframe() permet de visualiser le tableau enrichi. La deuxième couche est le Report, qui reçoit une liste d'évaluateurs ou de presets, par exemple TextEvals() ou DataDriftPreset(method="psi"). La troisième couche est la sortie : l'objet retourné par report.run() s'affiche dans un notebook, s'exporte en JSON avec my_eval.json(), en dictionnaire avec my_eval.dict(), ou en fichier HTML avec my_eval.save_html("file.html"). Ce qui distingue l'architecture, c'est que le même calcul sert à l'analyse ad hoc et à l'alimentation du tableau de bord. Rien n'est recalculé différemment selon la destination.

Transformer un rapport en test qui échoue

La Test Suite est la partie la plus utile pour une chaîne d'intégration. Le README explique qu'on transforme un Report en Test Suite en ajoutant des conditions de réussite ou d'échec, avec une syntaxe de comparaison du type gt et lt. Deux modes coexistent : écrire les conditions à la main, ou laisser la bibliothèque les générer automatiquement à partir du jeu de données de référence, ce que le README appelle l'option « zero setup ». Ce second mode mérite d'être abordé avec prudence. Une condition déduite automatiquement d'un échantillon de référence encode les propriétés de cet échantillon, y compris ses particularités. Sur un jeu de référence petit ou peu représentatif, la porte de CI héritera de cette fragilité sans que personne ne l'ait écrite explicitement. La documentation ne donne pas, dans le matériel fourni, de règle sur la taille minimale du jeu de référence ni sur le taux de faux positifs attendu. C'est un point à mesurer soi-même avant de brancher la suite sur une branche principale.

Installation et lancement de l'interface locale

L'installation tient en une commande : pip install evidently, ou conda install -c conda-forge evidently pour l'écosystème Conda. Pour l'interface de surveillance, deux chemins sont documentés. Avec uv, une seule ligne suffit : uv run --with evidently evidently ui --demo-projects all. Sans uv, le README propose de créer un environnement virtuel avec virtualenv venv puis source venv/bin/activate, avant de lancer, une fois Evidently installé, la commande evidently ui --demo-projects all. L'interface est ensuite accessible sur localhost:8000. L'option --demo-projects all charge des projets de démonstration, ce qui permet de voir à quoi ressemble le tableau de bord sans avoir de données à soi. Le README signale aussi une démonstration hébergée à l'adresse demo.evidentlyai.com. À noter que la commande d'interface est présentée comme une façon de lancer « a demo project in the locally hosted Evidently UI » : le matériel fourni ne détaille pas la procédure pour brancher une base de données de production sur cette même interface.

Ce que la version open source ne fait pas

C'est la limite la plus structurante du projet, et elle est énoncée par le README lui-même. La version auto-hébergée est présentée comme une option parmi deux, l'autre étant Evidently Cloud, décrit comme « Recommended » et comme apportant « dataset and user management, alerting, and no-code evals ». Autrement dit, l'alerte, la gestion des utilisateurs et l'évaluation sans code ne sont pas dans le périmètre open source. Une équipe qui déploie l'interface locale pour remplacer un système d'alerting devra construire cette couche elle-même, à partir des exports JSON ou des résultats de Test Suites. Le README renvoie à une page de comparaison OSS vs Cloud pour le détail, ce qui suggère que la frontière évolue au fil des versions. Deuxième réserve : la bibliothèque est très modulaire, et cette modularité a un coût. Composer un rapport sur mesure suppose de connaître les presets, les metrics individuelles et les descriptors, et de choisir soi-même la méthode de détection de dérive, comme le montre l'argument method="psi" passé à DataDriftPreset. Le défaut par défaut n'est pas neutre : selon la méthode retenue, la sensibilité au volume et aux variables catégorielles change. Enfin, avec plus de cent évaluations intégrées, la surface d'API est large, et rien dans le matériel fourni n'indique une stabilité garantie des noms d'imports entre versions mineures.

Face à un outil de test de données classique

La comparaison la plus instructive se fait avec Great Expectations, l'autre bibliothèque Python largement utilisée pour valider des données. La différence d'approche est nette. Great Expectations part de la notion d'attente déclarée sur une colonne, par exemple une plage de valeurs ou un ensemble de catégories autorisées, et vérifie que la donnée y satisfait. Evidently part d'une comparaison entre deux jeux : un jeu de référence et un jeu courant, et calcule un écart de distribution. Le README illustre exactement ce geste avec report.run(iris_frame.iloc[:60], iris_frame.iloc[60:]), où les soixante premières lignes servent de référence et les suivantes de données courantes. La conséquence pratique est double. Evidently détecte des dérives que personne n'a pensé à écrire sous forme de règle, mais il ne peut pas exprimer une contrainte métier absolue comme « l'âge doit être positif » sans passer par une condition de test explicite. Inversement, Great Expectations n'a pas de notion native de comparaison à une référence, ni de sortie orientée modèle comme une évaluation de sentiment. Les deux outils se recouvrent sur la validation de données tabulaires, et une équipe qui a déjà investi dans des suites d'attentes n'a pas de raison mécanique de migrer. Le cas où Evidently apporte quelque chose que l'autre ne couvre pas est l'évaluation de sorties générées, via les descriptors comme Sentiment ou Contains.

Licence, mises à jour et coût réel de suivi

Le dépôt est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec conservation des mentions de copyright et du fichier de licence. Elle ne couvre que le code du dépôt : l'utilisation d'Evidently Cloud relève d'un contrat de service distinct, et le README ne décrit pas les conditions de cette offre au-delà de la mention d'un palier gratuit. Sur le rythme de publication, les trois dernières versions listées s'échelonnent entre le 5 janvier 2026 et le 10 mars 2026, avec un intervalle d'environ deux mois entre v0.7.20 et v0.7.21. Le projet est toujours en série 0.7.x, donc en deçà de la 1.0, ce qui implique que des ruptures d'API restent possibles. Le coût de maintenance ne se situe pas dans la mise à jour du paquet lui-même, mais dans la revue des rapports après chaque montée de version : un preset dont le calcul change modifie les seuils des Test Suites et peut faire échouer une chaîne d'intégration sans qu'aucune ligne de code applicatif n'ait bougé. Épingler la version dans le fichier de dépendances et lire les notes de version avant de monter est la seule protection que le matériel fourni permette de recommander concrètement.

Conclusion éditoriale

Evidently convient aux équipes qui écrivent déjà du Python pour la data et veulent des évaluations reproductibles, exportables en JSON ou HTML, avec des conditions de réussite qui peuvent servir de porte en CI. Celles qui cherchent une plateforme d'observabilité avec alerting et gestion des accès doivent vérifier d'abord la page de comparaison OSS vs Cloud, car ces fonctions ne figurent pas dans la version open source. Avant tout déploiement, testez si le preset DataDriftPreset(method="psi") se comporte correctement sur vos colonnes catégorielles et vos valeurs manquantes : c'est le point où un preset générique se révèle le moins fiable.

Sources officielles

1. evidentlyai/evidently on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases