notte : un cadre Python pour agents web, avec un coeur open source et une couche hébergée

Le problème visé : automatiser le web sans écrire un script par site

Un script Playwright classique casse dès que le DOM change. Un agent purement conversationnel coûte cher à chaque étape et reste imprévisible. Notte se place entre les deux : le README parle d'un cadre qui combine agents IA et scripting traditionnel, en laissant « script deterministic parts » et en réservant le modèle aux moments où il est nécessaire. La cible est donc l'équipe qui doit extraire des données ou remplir des formulaires sur des sites qu'elle ne contrôle pas, et qui ne veut ni maintenir des dizaines de sélecteurs, ni payer un appel LLM pour cliquer sur un bouton dont la position est connue.

Le dépôt est en Python, avec une exigence affichée de Python 3.11 ou plus. Le paquet s'installe depuis PyPI, ce qui le rend accessible à un backend existant sans infrastructure particulière. Le projet se présente comme un cadre complet, mais la répartition est nette : le coeur open source fournit l'agent, la sortie structurée et les interactions de site ; les fonctions de session furtive, de coffre et de persona passent par le service API, donc par une clé obtenue sur la console Notte.

Sessions, agents et primitives Playwright : le mécanisme

L'unité de base est la session. Dans l'exemple local du README, on ouvre un contexte avec notte.Session(headless=False), on construit un notte.Agent en lui passant cette session, un reasoning_model et un max_steps, puis on appelle agent.run(task=...). Le modèle est désigné par une chaîne du type gemini/gemini-2.5-flash, ce qui suggère une couche d'abstraction au-dessus de plusieurs fournisseurs, mais le README ne documente pas la liste complète des modèles acceptés. C'est une zone à vérifier avant de choisir votre fournisseur.

La session expose des primitives compatibles Playwright, selon la description du dépôt, pour observer l'état d'une page, extraire des données et exécuter des actions, y compris en langage naturel. Autrement dit, l'agent ne remplace pas Playwright : il s'ajoute à côté. C'est ce qui rend le mode hybride crédible sur le papier. Le paramètre max_steps borne explicitement la boucle, ce qui est une bonne décision de conception : sans plafond, un agent qui tourne sur un site capricieux consomme des appels sans fin. Le README ne précise pas ce qui se passe lorsque la limite est atteinte, ni comment l'échec est remonté à l'appelant.

Sortie structurée : Pydantic comme contrat

La fonction run accepte un paramètre response_format qui prend un modèle Pydantic. L'exemple du README définit une classe HackerNewsPost avec titre, URL, points, auteur et nombre de commentaires, puis une classe TopPosts contenant une liste de ces objets. L'agent reçoit une tâche en langage naturel et renvoie une réponse dont on lit le champ answer.

Cette approche a un intérêt concret : le résultat n'est pas du texte à parser, c'est un objet validé par le schéma. Pour un pipeline d'ingestion, cela déplace la validation au moment de l'exécution plutôt qu'après coup. La contrepartie est classique : si le site ne fournit pas un champ demandé, le modèle doit inventer une valeur ou échouer, et le README ne décrit pas la politique de Notte dans ce cas. Un champ points manquant sur une page Hacker News est un scénario banal. Prévoyez de traiter les valeurs par défaut comme suspectes.

Coffre d'identifiants et personas : ce qui reste hors du coeur open source

Deux objets sont documentés avec des exemples. Le coffre, via client.Vault(), permet d'enregistrer un couple URL, nom d'utilisateur, mot de passe avec vault.add_credentials, puis de l'attacher à un agent avec le paramètre vault. L'agent s'en sert automatiquement lorsqu'un formulaire de connexion apparaît. Le persona, via client.Persona(create_phone_number=False), fournit une identité numérique avec adresse électronique, numéro de téléphone et gestion automatisée du 2FA, selon la description du projet.

Ces deux fonctions relèvent de la liste des services API. Le README les présente sous l'API service (Recommended), pas sous Opensource Core. C'est la ligne de partage la plus importante du projet : l'automatisation de base est ouverte, la gestion d'identités et de secrets ne l'est pas. Pour un cas d'usage qui exige de créer des comptes ou de se connecter à un service protégé par 2FA, vous dépendez donc d'un service tiers, avec les questions de résidence des données que cela implique. Le dépôt ne donne aucune information sur le stockage de ces secrets.

Mise en route : deux commandes et une variable d'environnement

L'installation tient en deux lignes : pip install notte, puis patchright install --with-deps chromium. Le second outil n'est pas Playwright mais patchright, un dérivé orienté furtivité, ce qui est cohérent avec la promesse de sessions anti-détection. Le README ne détaille pas les différences entre les deux, ni les plateformes couvertes par cette commande.

En mode local, il faut fournir ses propres clés de modèle, par exemple via un fichier .env chargé par load_dotenv. En mode SDK, la clé s'obtient sur console.notte.cc et se lit depuis la variable NOTTE_API_KEY, puis on construit un NotteClient. Le passage de l'un à l'autre est présenté comme un remplacement d'import et de préfixe : les objets notte deviennent des objets du client. C'est un argument pratique réel pour prototyper en local avant de basculer. La bascule n'est toutefois pas neutre, puisque certaines fonctions n'existent que d'un côté.

Les chiffres du README et ce qu'ils ne disent pas

Le README publie un tableau comparatif avec Notte à 86,2 % en auto-évaluation, 79,0 % en évaluation par LLM, 47 secondes par tâche et 96,6 % de fiabilité, face à Browser-Use et Convergence. Ces chiffres proviennent du dépôt open-operator-evals, cité comme source, et sont donc auto-déclarés par l'éditeur du projet. Le tableau lui-même distingue Agent Self-Report et LLM Evaluation, ce qui est plus honnête que la moyenne, mais rien dans le matériel fourni ne permet de savoir quelles tâches composent le jeu d'évaluation, combien elles sont, ni comment la fiabilité est mesurée. Traitez ces valeurs comme une indication de la méthode d'évaluation, pas comme une garantie sur votre site cible.

Autre point : le README affirme une réduction de coûts de plus de 50 % grâce au mode hybride. Aucun détail de calcul n'accompagne cette affirmation. Elle dépend entièrement du prix de votre modèle et de la proportion d'étapes que vous parvenez réellement à scripter.

Licence SSPL-1.0 : la contrainte à lire avant d'adopter

Le badge du dépôt indique SSPL-1.0, alors que les métadonnées de la plateforme signalent NOASSERTION. Cette divergence mérite une lecture directe du fichier de licence. La SSPL est une licence copyleft forte, conçue à l'origine pour les bases de données, qui étend les obligations de publication au-delà du code distribué lorsque le logiciel est proposé comme service. Concrètement, si vous exposez une version modifiée de Notte à des utilisateurs, les obligations ne se limitent pas au binaire que vous livrez.

Je ne donne pas d'avis juridique et le dépôt ne fournit pas de FAQ de licence. Si votre organisation exclut ce type de licence, c'est un point bloquant qui se règle avant l'évaluation technique, pas après. Le rythme de publication est élevé : trois versions en trois jours d'après les releases listées, ce qui suggère un projet actif mais aussi une surface d'API encore mouvante.

Quand Notte n'est pas le bon outil

Si votre cible est un site que vous contrôlez, ou une API documentée, l'agent est une couche inutile. Une requête HTTP et un parseur font le travail sans modèle, sans navigateur et sans latence d'inférence. De même, un site dont la structure est stable depuis des mois se traite très bien avec Playwright seul, et vous évitez d'introduire une dépendance à un raisonnement probabiliste dans une chaîne déterministe.

Le cas défavorable le plus net concerne les environnements sans accès sortant vers un service tiers. Les fonctions de coffre, de persona et de session furtive sont rattachées à l'API hébergée. Si vous devez tout exécuter sur votre infrastructure, vous vous limitez au coeur open source et vous perdez précisément les briques qui traitent les sites hostiles. Le README ne décrit pas d'option d'auto-hébergement pour ces fonctions. Enfin, la limite max_steps et la variabilité du modèle impliquent qu'un même run peut produire des résultats différents. Sur un flux qui exige une reproductibilité stricte, cela se paie en tests de non-régression.

Conclusion éditoriale

Notte convient aux équipes Python qui veulent écrire des automatisations web où le script gère les étapes déterministes et le LLM seulement le reste, en acceptant la licence SSPL-1.0 et le passage à la couche hébergée pour les fonctions furtives. À éviter si vous ne pouvez pas dépendre d'un service externe ou si votre cas d'usage tient dans quelques sélecteurs CSS stables. Avant de vous engager, vérifiez trois choses dans le dépôt : le texte exact de la licence, la version de Python exigée (3.11+) et la disponibilité du modèle de raisonnement que vous comptez passer à reasoning_model.

Sources officielles

1. Issues
2. nottelabs/notte on GitHub
3. Project website
4. README
5. Releases