Comment utiliser Pi coding agent sans usine à gaz ?

Pi coding agent sert à coder avec un agent minimaliste, sans empiler des fonctions cachées partout. L’idée est simple : quatre outils de base, un prompt système court, et le reste à construire via extensions. Je vous montre ce que ça change vraiment, comment l’installer, et où sont les limites.

Pourquoi Pi fait volontairement moins ?

Pi fait moins, et c’est précisément ce qui m’intéresse. Dans un monde où chaque agent de codage veut devenir un cockpit d’avion, Pi prend une direction presque bizarre au début. Il ne cherche pas à tout embarquer dans son noyau. Il ne veut pas devenir l’endroit magique où des décisions se prennent sans que vous sachiez vraiment pourquoi.

Concrètement, Pi refuse de mettre pas mal de choses au centre de l’outil. Pas par oubli. Pas parce que l’équipe n’y a pas pensé. C’est une décision de design.

• Pas de MCP dans le noyau. MCP, pour Model Context Protocol, sert à connecter un agent à des outils et des sources de données externes. C’est puissant, mais ça élargit vite la surface de risque.
• Pas de sous-agents. Donc pas de petites entités internes qui partent travailler dans leur coin avec leur propre logique.
• Pas de plan mode imposé. L’agent ne vous enferme pas dans une mécanique interne où il planifie tout selon sa propre structure.
• Pas de popups de permissions partout. Je préfère une action claire à une fausse impression de contrôle avec quinze confirmations.
• Pas de listes de tâches intégrées. Votre gestion de travail reste dans vos outils, pas cachée dans l’agent.
• Pas d’exécution bash en arrière-plan. Bash, c’est le terminal Linux ou macOS. C’est très utile, mais aussi très sensible quand ça tourne sans visibilité.

Sur le papier, ça peut sembler pauvre. Je l’ai déjà vu chez un client. Première réaction de l’équipe : “Mais il manque plein de trucs”. Puis on a commencé à le brancher dans leur workflow de dev, avec leurs règles de sécurité, leurs revues de code, leurs scripts CI, leurs logs. Et là, le côté “moins malin tout seul” est devenu un avantage.

Parce qu’en entreprise, le sujet n’est pas juste de générer du code vite. Il faut comprendre ce que l’agent fait. Il faut pouvoir reproduire une action. Il faut auditer. Il faut expliquer à un responsable sécurité pourquoi tel fichier a été modifié et par quel chemin. Moins il y a de comportements invisibles, moins vous dépendez d’une logique interne opaque.

C’est ça l’approche de Pi. Réduire la magie dans le noyau pour garder une surface explicite, maîtrisable, branchable proprement. Avant de juger l’outil comme “trop simple”, il faut donc regarder ce qu’il y a vraiment dans ce noyau, et pourquoi ça suffit souvent largement.

Que contient vraiment le noyau de Pi ?

Le noyau de Pi contient seulement quatre outils : read, write, edit et bash. C’est volontairement petit. Et franchement, c’est plutôt rare dans un monde où chaque agent arrive souvent avec une valise de fonctions, de plugins, de workflows et de comportements qu’on découvre après coup.

Avec Pi, le cœur reste lisible. Read sert à lire des fichiers. Write sert à créer ou réécrire du contenu. Edit sert à modifier un fichier existant sans tout remplacer. Bash sert à exécuter des commandes dans l’environnement, comme lancer des tests, installer une dépendance ou inspecter un dossier. Rien de mystique là-dedans.

Outil	Rôle	Intérêt pratique
Read	Lire les fichiers	Comprendre le code ou la configuration avant d’agir
Write	Écrire du contenu	Créer un fichier ou remplacer un contenu clairement
Edit	Modifier un fichier existant	Faire une correction ciblée sans tout casser
Bash	Exécuter des commandes	Lancer des tests, explorer le projet, vérifier le résultat

Ce qui compte presque autant, c’est ce qui n’est pas là. Pas de couche fonctionnelle massive par défaut. Pas d’automatisation magique embarquée. Pas de longue liste d’outils imposés qui consomment du contexte avant même que l’agent ait lu votre vrai problème.

Le system prompt est court, sous 1 000 tokens. Un token, pour faire simple, c’est un petit morceau de texte consommé par le modèle. Plus le prompt système est long, moins il reste de place pour votre code, vos fichiers, vos erreurs, vos consignes. J’ai vu des setups où l’agent passait plus de temps à porter son propre mode d’emploi qu’à comprendre le projet. Là, l’idée est inverse : garder de l’espace pour le contexte utile.

Les consignes passent plutôt par des fichiers AGENTS.md. Il peut y en avoir un global, pour vos préférences générales, et un par projet, pour les règles locales. C’est explicite. Vous savez ce que l’agent lit. Vous pouvez le modifier. Ce n’est pas un comportement caché injecté quelque part.

Cette base minimaliste prend son sens seulement si l’installation et l’usage réel restent simples.

Comment installer et vérifier Pi ?

Je préfère toujours installer ce genre d’outil dans un environnement propre. Ça évite de mélanger un problème de Pi avec un vieux Node, un PATH cassé ou un package global installé il y a six mois.

Avant de toucher à Pi, je vérifie les bases. Il faut au minimum :

• Node.js 22 ou plus récent.
• Npm installé avec Node.
• Un terminal classique.
• Une clé API Anthropic, OpenAI ou Google si vous voulez lancer de vraies sessions avec un modèle.

Le premier mode d’installation passe par npm. C’est celui que je prends quand je veux rester dans un setup Node standard, facile à comprendre et à nettoyer.

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

Le deuxième mode passe par le script standalone. C’est pratique si vous voulez aller vite, ou si vous ne voulez pas gérer le package npm directement.

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

Je reste prudent avec les scripts d’installation en une ligne. Ça peut être très pratique, mais je préfère le faire dans une machine de test, un conteneur, ou au moins un environnement où je sais exactement ce que je modifie. Selon votre OS, votre shell, vos droits utilisateur ou votre configuration Node, le résultat peut varier.

Une fois l’installation terminée, le vrai test simple, c’est de vérifier que le binaire répond.

pi –version

Dans mon test, la commande m’a retourné la version 0.80.3. C’est suffisant pour valider que Pi est bien installé et accessible depuis le terminal. Pas besoin d’aller plus loin à ce stade.

Petite nuance importante. Installer Pi, c’est une chose. Lancer une vraie session avec un modèle, c’en est une autre. Là, il faut une clé API valide, selon le fournisseur que vous utilisez : Anthropic, OpenAI ou Google. Sans ça, vous pouvez avoir un binaire installé proprement, mais rien d’exploitable côté IA.

Pour moi, l’installation n’est pas le sujet difficile. Le vrai sujet, c’est ce qu’on fait après. Comment on étend Pi proprement, sans bricoler une usine à gaz autour d’un agent qui devrait justement nous simplifier le travail.

Comment étendre Pi sans l’alourdir ?

Pi s’étend par des points d’extension, pas en surchargeant son noyau. C’est un détail qui change tout. Quand je regarde un agent de code, je me méfie toujours du moment où il commence à tout faire dans le même bloc : lire, décider, modifier, orchestrer, historiser, appeler des services, gérer les règles métier. Ça finit rarement bien.

La bonne logique avec Pi, c’est de tester une extension TypeScript, donc une extension écrite avec TypeScript, le JavaScript typé, pour observer le comportement réel au lieu d’imaginer une API magique. Je ne rajoute pas des capacités dans le cœur juste parce que c’est pratique sur le moment. Je branche autour. Je garde le noyau lisible, stable, compréhensible.

Pour une équipe data, IA ou automatisation low code, c’est très concret. Vous pouvez ajouter un comportement utile sans accepter un agent monolithique qui décide trop de choses tout seul. Par exemple, une règle de validation, une intégration avec un outil interne, une étape de contrôle, une façon de préparer un contexte métier. Le cœur reste le moteur. Les cas métier vivent à côté.

C’est exactement ce que je recommande dans une bonne architecture d’automatisation. Le socle doit rester simple. Les workflows, les exceptions, les connecteurs et les règles propres au métier doivent être isolés. Sinon, au bout de six mois, plus personne n’ose toucher au système. J’ai vu ça chez un client avec un agent maison “temporaire”. Tout était dedans. Même corriger une règle de nommage devenait risqué.

Il y a aussi un point de gouvernance important. Le noyau de Pi reste sous licence MIT selon le RFC 0015, donc une licence permissive qui permet l’usage, la modification et la redistribution avec peu de contraintes. Ça n’empêche pas des couches payantes ou des services hébergés d’exister autour, comme Lefos. Ce n’est pas contradictoire. C’est même assez sain si la frontière est claire.

Le contexte compte aussi. Pi a été créé par Mario Zechner, avec un soutien public d’Armin Ronacher, puis il y a eu l’acquisition par Earendil Inc. Et le lancement de Lefos. Je ne prends pas ça comme un argument marketing. Je le lis plutôt comme un signal d’architecture : garder un noyau ouvert, permettre des extensions, et laisser des services plus intégrés exister autour.

Couche	Rôle	Ce que ça évite
Noyau minimal	Garder le comportement central simple, lisible et stable.	Un agent opaque qui mélange tout.
Extensions	Ajouter des capacités métier autour du cœur, sans le modifier lourdement.	Des règles enfouies dans le moteur.
Services hébergés	Fournir une expérience prête à l’emploi, de l’orchestration ou du support.	Confondre produit commercial et base open source.

Alors Pi est-il le bon agent pour votre façon de coder ?

Pi coding agent vaut le coup si vous cherchez un agent lisible, extensible, et pas une boîte noire qui embarque tout par défaut. Son noyau se limite à read, write, edit et bash. Le reste passe par des extensions, des fichiers AGENTS.md, et vos propres choix d’architecture. J’aime bien cette logique parce qu’elle oblige à être clair sur ce qu’on automatise vraiment. Ce n’est pas forcément l’outil le plus confortable au premier contact, surtout si vous attendez des workflows déjà prêts. Mais pour une équipe qui veut maîtriser son agent de codage, le bénéfice est net : moins de magie, plus de contrôle.

FAQ

• Qu’est-ce que Pi coding agent ?
  Pi coding agent est un assistant de codage minimaliste. Son noyau embarque peu de fonctions et laisse les capacités avancées aux extensions ou aux choix de l’utilisateur. L’idée, c’est de garder un agent plus lisible et plus contrôlable.
• Quels sont les outils intégrés dans Pi ?
  Pi intègre seulement quatre outils dans son noyau : read, write, edit et bash. Il ne fournit pas par défaut de sous-agents, de plan mode, de listes de tâches intégrées ou de système MCP embarqué.
• Quels prérequis faut-il pour installer Pi ?
  Il faut Node.js 22 ou plus, npm, un terminal, et une clé API Anthropic, OpenAI ou Google si vous voulez lancer de vraies sessions avec un modèle. L’installation peut se faire via npm ou via un script standalone.
• Pourquoi Pi utilise un prompt système court ?
  Pi réduit volontairement la taille du system prompt, sous 1 000 tokens, pour préserver le budget de contexte. Ça évite de consommer trop de place avec des instructions internes longues et ça rend le comportement de l’agent plus explicite.
• Pi est-il adapté à une équipe business ou technique ?
  Pi peut être intéressant pour une équipe qui veut maîtriser précisément ce que fait son agent de codage. Son approche minimaliste demande plus de cadrage, mais elle réduit les comportements cachés et facilite une logique d’extension plus propre.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Avec mon agence webAnalyste et l’organisme Formations Analytics, j’accompagne des équipes qui veulent connecter data, IA et automatisation sans créer des usines à gaz. 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 agents IA, vos workflows ou vos projets data proprement, contactez-moi.