Pi Coding Agent vaut-il le coup pour coder ?

Pi Coding Agent vaut le coup si vous cherchez un agent simple, lisible et contrôlable. Ici, je regarde ce qu’il fait vraiment, pourquoi il refuse plein de fonctions à la mode, comment l’installer, et comment le tester sans se raconter d’histoire.

C’est quoi Pi Coding Agent ?

Pi Coding Agent est un agent de codage minimaliste pensé pour travailler avec peu de contexte caché et peu de magie.

Ce que je trouve intéressant avec Pi, ce n’est pas qu’il promette de tout faire à votre place. C’est presque l’inverse. Son idée, c’est de garder le comportement de l’agent visible, lisible, prévisible. Pas d’empilement d’extensions dans tous les sens, pas une boîte noire qui modifie votre projet avec trois intentions que vous n’avez jamais validées.

Le projet est principalement porté par Mario Zechner, que beaucoup connaissent déjà pour son travail côté tooling et développement. L’histoire a ensuite pris un peu plus d’ampleur avec le soutien d’Armin Ronacher, puis l’acquisition par Earendil Inc. Derrière, on voit aussi arriver Lefos, la plateforme cloud liée à cet écosystème. Et il y a un point que j’aime bien voir dans ce genre de projet : un document de gouvernance, RFC 0015, qui pose un cadre sur la direction du projet. Une RFC, pour faire simple, c’est un document de discussion formalisé. Ça permet d’éviter que tout repose uniquement sur des décisions opaques prises dans un coin.

Le cœur de Pi est annoncé sous licence MIT. Ça veut dire que la base est très permissive côté usage, modification et redistribution. À côté de ça, il peut exister des couches payantes ou en Fair Source. Fair Source, c’est une approche où le code est accessible, mais avec certaines limites commerciales ou temporelles selon la licence choisie. Donc oui, il faut lire les détails si vous comptez l’intégrer sérieusement dans une stack pro.

Je n’ai pas de chiffre vérifié à donner sur l’adoption GitHub, donc je ne vais pas en inventer un. Ce qu’on peut dire proprement, c’est que le projet a connu une adoption rapide pour un outil aussi spécialisé. La version que j’ai testée est la 0.80.3, vérifiée simplement avec :

pi --version

Ce contexte compte vraiment si vous codez avec des agents IA. Quand un agent décide trop de choses en arrière-plan, on perd vite la main. On ne sait plus ce qui vient du modèle, de l’outil, du prompt système, ou d’une automatisation cachée. Pi prend l’option inverse. Pour comprendre cette approche, il faut maintenant regarder ce que Pi embarque vraiment, et surtout ce qu’il refuse d’embarquer.

Pourquoi Pi fait-il moins ?

Pi fait moins pour laisser plus de place au travail utile du modèle, et pour éviter un agent opaque qui change de comportement sans que vous le voyiez. C’est vraiment le cœur du choix. Moins de magie autour, plus de contrôle sur ce qui se passe dans votre repo.

Pi tourne autour de quatre outils simples. Pas cinquante couches d’orchestration, pas un cockpit d’avion. Juste ce qu’il faut pour coder dans une session réelle.

• L’outil read sert à lire les fichiers. C’est la base, parce qu’un agent qui modifie du code sans avoir lu le contexte, c’est souvent le début des ennuis.
• L’outil write sert à créer un fichier ou à remplacer complètement son contenu. Je l’utilise plutôt quand on génère quelque chose de neuf, ou quand le fichier est petit et clair.
• L’outil edit sert à modifier précisément une partie d’un fichier. C’est celui qu’on veut voir utilisé quand il faut toucher une fonction, une config, une ligne, sans massacrer le reste.
• L’outil bash sert à exécuter des commandes dans le terminal. Tests, installation, lint, build, recherche avec grep, ce genre de choses.

Les absences sont volontaires. Pas de MCP intégré, c’est-à-dire pas de Model Context Protocol branché par défaut pour connecter plein de sources externes. Pas de sous-agents. Pas de mode plan séparé. Pas de popups de permission à répétition. Pas de to-do intégrés. Pas d’exécution bash en arrière-plan.

Je ne vois pas ça comme des manques idiots. Je le vois comme une philosophie de design. Pi évite d’empiler des mécanismes qui peuvent être pratiques en démo, mais qui deviennent vite pénibles quand il faut comprendre pourquoi l’agent a pris telle décision.

L’argument des tokens est important aussi. Pi vise un prompt système très court, inférieur à 1 000 tokens. Un token, pour simplifier, c’est un morceau de texte que le modèle consomme pour réfléchir et répondre. Moins le système mange de budget, plus il reste de place pour votre code, vos fichiers, votre demande réelle.

J’ai souvent vu l’inverse chez des clients. Des outils bourrés de contexte automatique, très séduisants au premier rendez-vous, mais horribles à diagnostiquer quand le résultat part de travers. On ne sait plus si le problème vient du prompt, d’une règle cachée, d’un connecteur, d’un agent secondaire, ou d’une permission acceptée trop vite.

Avec Pi, le mécanisme principal pour injecter des règles, c’est AGENTS.md. C’est un fichier visible, lisible, modifiable. Si une règle influence l’agent, elle doit être lisible. C’est simple, mais ça change beaucoup de choses.

Inclus	Absent volontairement
Outils read, write, edit, bash	MCP, sous-agents, mode plan
AGENTS.md visible	Contexte caché et popups de permission
Prompt système court	To-do intégrés et bash en arrière-plan

Comment installer Pi proprement ?

Pour installer Pi proprement, il faut un environnement Node.js récent, npm, un terminal, puis choisir entre l’installation npm et le script standalone. Rien de très exotique, mais je préfère poser ça proprement, parce que les galères d’installation viennent souvent d’un Node trop vieux ou d’un terminal mal configuré.

Les prérequis sont simples :

• Node.js 22 ou plus.
• Npm, le gestionnaire de paquets installé avec Node.js dans la plupart des cas.
• Un terminal, sur macOS, Linux ou Windows avec un environnement adapté.
• Une clé API si vous voulez lancer de vraies sessions avec des fournisseurs comme Anthropic, OpenAI ou Google.

La méthode npm est celle que je privilégie quand je veux garder un minimum de contrôle sur ce qui est installé. Le paquet à utiliser est @earendil-works/pi-coding-agent, avec l’option –ignore-scripts. Cette option évite l’exécution automatique de scripts pendant l’installation, ce qui est souvent plus propre, surtout dans un contexte pro.

npm install -g @earendil-works/pi-coding-agent --ignore-scripts

L’autre option, c’est l’installation standalone via un script shell. C’est plus direct, souvent plus rapide, mais ça mérite un peu plus d’attention.

curl https://pi.dev/install.sh | sh

Je vais être franc, je n’aime pas lancer des scripts curl à l’aveugle en entreprise. Sur une machine perso ou un environnement jetable, ça peut passer. Dans un contexte sensible, je préfère toujours récupérer le script, lire ce qu’il fait, vérifier les chemins modifiés, les binaires téléchargés, les permissions, puis seulement après l’exécuter.

Une installation réussie doit être rapide. Une fois Pi installé, je vérifie simplement que la commande répond bien.

pi --version

Dans mon test, le retour observé était 0.80.3. C’est suffisant pour valider que l’outil est présent et accessible dans le terminal.

Mais soyons clairs, la vraie validation ne s’arrête pas à une commande de version. Une fois l’outil installé, le vrai test, c’est une session concrète avec lecture de fichiers, modification, écriture et exécution. C’est là qu’on voit si Pi tient vraiment la route pour coder.

Comment tester Pi en vraie session ?

Le bon test consiste à lui donner une tâche de codage réelle, pas une démo jouet, puis à observer comment il lit, modifie, écrit et exécute le code. C’est là qu’on voit vite si Pi est utile, ou si on est juste en train de discuter avec un chatbot qui parle bien.

Je ferais un test assez simple, mais pas simpliste. Installer Pi, vérifier la version, ouvrir un vrai projet, puis lui demander d’écrire une petite extension TypeScript. TypeScript, c’est du JavaScript avec des types, donc ça force l’agent à respecter une structure de code un peu plus stricte. Ensuite, je lance le résultat dans le binaire live, c’est-à-dire l’exécutable réel, pas une simulation dans le vide.

Cette méthode est plus intéressante qu’un test conversationnel parce qu’elle oblige Pi à toucher au projet. Il doit lire les fichiers, comprendre où intervenir, modifier ou écrire du code, puis utiliser le terminal via bash. Bash, c’est juste l’interface en ligne de commande qui permet de lancer des commandes comme installer une dépendance, compiler ou exécuter des tests. Là, on teste ses quatre outils dans une vraie boucle de travail, pas sa capacité à répondre joliment.

Pendant la session, je regarde surtout quelques signaux très concrets :

• Quels fichiers Pi lit avant de modifier quoi que ce soit.
• Quelles modifications il propose, et si elles restent localisées.
• Comment il utilise bash, avec des commandes utiles ou des commandes au hasard.
• Si les consignes du fichier AGENTS.md sont respectées.
• Si le résultat final reste compréhensible pour un humain pressé.

Le minimalisme de Pi aide beaucoup ici. Il y a moins de couches invisibles entre votre demande et son action. J’ai déjà vu des agents très “riches” produire des plans magnifiques, puis partir dans tous les sens dès qu’ils touchent au repo. Avec Pi, la session est plus sèche, mais souvent plus facile à auditer.

Il faut quand même être clair. Pi n’est pas conçu pour tout faire à votre place. Si vous attendez des sous-agents, des plans automatiques, du suivi de tâches intégré ou des permissions en popup, ce n’est pas son terrain. Son intérêt est ailleurs : garder une boucle courte entre votre intention, le code, le terminal et le résultat.

Vous cherchez	Pi est adapté ?
Un agent simple à auditer	Oui
Un outil avec beaucoup d’orchestration intégrée	Pas vraiment
Un prompt système court et visible	Oui
Des sous-agents et du mode plan natif	Non

Et si le bon agent était juste plus simple ?

Pi Coding Agent m’intéresse parce qu’il prend une direction assez rare : il retire des choses au lieu d’en ajouter. Quatre outils, un prompt système court, un fichier AGENTS.md visible, pas de couches cachées qui décident à votre place. Ça ne conviendra pas à tout le monde. Si vous voulez un copilote très orchestré, avec plans, sous-agents et automatisations intégrées, vous allez le trouver trop sec. Si vous voulez comprendre ce que l’agent fait dans votre code, l’installer vite, le tester proprement et garder la main, Pi devient sérieux. Le bénéfice pour vous, c’est moins de magie et plus de contrôle.

FAQ

• Pi Coding Agent sert à quoi ?
  Pi Coding Agent sert à travailler sur du code avec un agent volontairement simple. Il lit les fichiers, écrit, modifie et exécute des commandes bash. Son intérêt, c’est de garder peu de contexte caché et de rendre le comportement de l’agent plus facile à comprendre.
• Quels sont les outils intégrés dans Pi ?
  Pi embarque quatre outils : read, write, edit et bash. C’est tout. Il ne cherche pas à ajouter des sous-agents, un mode plan, des to-do intégrés ou des popups de permission. Ce choix réduit la complexité et limite le contexte invisible.
• Pourquoi Pi n’intègre pas MCP ou des sous-agents ?
  Pi les laisse volontairement de côté pour garder un cœur minimaliste. L’idée est de réduire le prompt système, annoncé sous les 1 000 tokens, et de laisser plus de budget au modèle pour traiter la demande, les fichiers et le code utile.
• Comment installer Pi Coding Agent ?
  Il faut Node.js 22 ou plus, npm et un terminal. L’installation peut se faire via npm avec le paquet @earendil-works/pi-coding-agent, idéalement avec –ignore-scripts, ou via le script standalone curl https://pi.dev/install.sh | sh. La version peut ensuite être vérifiée avec pi –version.
• Pi Coding Agent est-il fait pour tous les développeurs ?
  Pas forcément. Il convient surtout si vous voulez un agent simple, contrôlable et lisible. Si vous cherchez un outil très complet avec orchestration, sous-agents et suivi de tâches intégré, Pi risque de sembler trop minimaliste. Si vous voulez garder la main, c’est justement son intérêt.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des équipes sur le tracking server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA en entreprise et le SEO/GEO. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer vos usages IA, automatiser vos workflows ou rendre vos agents plus fiables, contactez-moi.