Pi Coding Agent : installer et prendre en main Pi 1.0

Pi Coding Agent vous laisse choisir le fonctionnement de l’agent

Pi est un socle minimal pour agent : il relie un modèle à vos fichiers et à vos commandes. Imaginez un établi : le modèle que vous choisissez décide des actions à mener, et Pi lui fournit les outils pour les exécuter.

Ses quatre outils intégrés activés par défaut couvrent le cycle de travail essentiel :

Le modèle demande l’utilisation d’un outil, Pi l’exécute, puis le résultat revient dans la conversation. Ce cycle peut se répéter jusqu’à la fin de la tâche. Il s’agit des quatre outils activés par défaut, pas de la liste complète des outils intégrés disponibles dans la version 1.0. Référence des outils de Pi, boucle de l’agent.

Si vous utilisez déjà Claude Code ou Codex, évaluez Pi en fonction du workflow que vous souhaitez maîtriser. Mon conseil : essayez-le lorsque vous avez une personnalisation précise en tête, par exemple une commande de revue du dépôt ou une skill de migration réutilisable. Pour comparer d’autres options, consultez la sélection d’agents de développement compatibles avec plusieurs modèles.

Pi 1.0 fait évoluer le terminal et l’exécution des outils

La version 1.0.0 active le plein écran par défaut et affine le codemode ainsi que la connexion aux comptes. Une TUI est une interface affichée dans le terminal. Voici les changements qui comptent pour la prise en main :

MCP relie l’agent à des outils externes. OAuth est le parcours de connexion qui autorise un accès sans communiquer votre mot de passe à l’outil. Le codemode permet au modèle de composer des appels d’outils en JavaScript et de renvoyer uniquement les résultats sélectionnés dans la conversation. La réduction du prompt concerne ce fonctionnement précis ; elle ne promet pas une facture réduite de 40% pour chaque tâche. Notes de version de Pi 1.0.0, documentation du codemode.

Cette même version ajoute la génération d’images depuis les scripts codemode, Radius dans /login et quietStartup: "header". Ces fonctions peuvent attendre votre première tâche de développement. Notes de version.

Installer Pi et réaliser une première tâche en 28 minutes

Partez d’un dépôt que vous connaissez, d’une commande de test qui fonctionne et d’un accès à un modèle pris en charge. Le découpage ci-dessous est un budget indicatif : la durée des téléchargements, de la connexion et des tests dépend de votre environnement. Choisissez une tâche assez limitée pour pouvoir en vérifier le résultat avant la fin de la session.

De 0 à 5 minutes : installer Pi et ouvrir le projet

L’installation via npm nécessite Node.js 22.19 ou une version ultérieure. Cette commande fixe la version de Pi à 1.0.0 pour suivre le guide avec la version présentée ici :

node --version
npm install -g --ignore-scripts @earendil-works/pi-coding-agent@1.0.0
pi --version
cd /path/to/project
pi --tui-mode regular

Remplacez /path/to/project par votre répertoire de travail. La commande pi --version doit afficher 1.0.0. Un simple pi utilise le nouveau mode plein écran par défaut. L’autre méthode officielle pour macOS/Linux, curl -fsSL https://pi.dev/install.sh | sh, installe la version courante. Documentation d’installation du projet, guide de démarrage.

De 5 à 10 minutes : connecter votre compte existant

Dans Pi, lancez /login, sélectionnez votre fournisseur et suivez la méthode d’authentification proposée. Lancez ensuite /model et choisissez un modèle disponible. Le fournisseur est votre voie d’accès ; le modèle est le système qui génère les réponses.

La documentation d’authentification de Pi mentionne l’accès par abonnement Anthropic et la connexion Sign in with ChatGPT d’OpenAI. OpenAI présente l’utilisation de l’abonnement comme une autorisation pour les requêtes éligibles, sous réserve de l’éligibilité du compte. L’utilisation d’une clé API relève d’une facturation distincte. Fournisseurs OAuth de Pi, documentation de connexion OpenAI.

Le site de Pi cite notamment Anthropic, OpenAI, Google, OpenRouter et Ollama. La prise en charge d’un fournisseur ne rend pas tous ses modèles disponibles sur tous les comptes. Si un modèle manque, vérifiez d’abord l’authentification : /model affiche les modèles pour lesquels vous disposez d’identifiants utilisables. Dans le sélecteur, appuyez sur Ctrl+S pour enregistrer votre choix par défaut. Documentation de sélection des modèles.

Pour Ollama, suivez l’exemple d’endpoint compatible du projet dans ~/.pi/agent/models.json : il utilise http://localhost:11434/v1, le type d’API openai-completions, la clé factice ollama et un identifiant de modèle servi par votre installation. L’ouverture de /model recharge ce fichier. C’est la voie locale pour essayer Pi sans compte de modèle payant.

De 10 à 13 minutes : donner à Pi les consignes du dépôt

Ajoutez un court fichier AGENTS.md à la racine du dépôt, ou complétez celui que vous maintenez déjà. Pi recherche les instructions dans ~/.pi/agent/, les répertoires parents et le répertoire courant. Si vous les modifiez pendant une session, lancez /reload. Documentation de configuration.

Rédigez des consignes adaptées à votre dépôt. Par exemple :

Use the existing test runner and neighboring test conventions.
Keep this task within the function and tests I name.
Do not add dependencies or change the public API.
Run the focused tests and report the exact command and result.
Leave commits and publishing to me.

Si vous la connaissez, ajoutez la commande exacte qui lance les tests ciblés. AGENTS.md oriente le modèle ; il n’impose aucune limite à ses autorisations.

De 13 à 23 minutes : apporter une modification utile

Choisissez une fonction utilitaire existante dont le comportement en cas d’entrée vide est défini, mais n’est pas encore couvert par un test de non-régression. Joignez cette fonction et un test voisin avec @, le sélecteur de fichiers de Pi, puis confiez-lui cette tâche :

Un test de non-régression protège un comportement attendu contre une modification qui le casserait plus tard. Cette tâche produit un diff concret sans demander à Pi de revoir la conception de votre application. Le guide de démarrage explique la sélection de fichiers avec @ et la vérification des fichiers modifiés après une tâche. Documentation de la première tâche.

De 23 à 28 minutes : vérifier le résultat

Lisez le test modifié et examinez git diff, qui présente les changements apportés aux fichiers. Vérifiez que l’assertion porte bien sur le comportement attendu, puis relancez vous-même la commande de test ciblée. Des tests réussis apportent un élément de validation ; à vous de juger si l’assertion est utile et si la modification reste dans le périmètre prévu.

Pour cette première session, l’objectif est simple : le fournisseur choisi a fonctionné, Pi a réalisé la modification attendue et vous pouvez expliquer le diff. Gardez la personnalisation pour la session suivante.

Pi est un logiciel libre ; le modèle détermine la facture

La licence MIT de Pi n’ajoute aucun coût de licence par utilisateur. L’accès par abonnement consomme les ressources prévues par votre formule ; une clé API entraîne la facturation à l’usage du fournisseur. Avec un modèle local, le coût se reporte sur votre matériel et son exploitation.

Prenons un exemple chiffré pour l’API. OpenAI facture l’utilisation standard de GPT-6.1 Sol avec un contexte court à $2 par million de tokens en entrée et $10 par million de tokens en sortie. Les tokens sont les unités de contenu comptabilisées pour la facturation. Tarifs officiels d’OpenAI.

Supposons qu’une petite tâche cumule l’utilisation suivante sur l’ensemble de ses requêtes :

Ce calcul sert d’illustration ; il ne correspond pas à une mesure réalisée sur une tâche. Il suppose un traitement standard, des requêtes ne dépassant pas chacune 272,000 tokens en entrée, et aucune écriture en cache ni aucun outil facturé séparément. Les entrées en cache, les écritures en cache, les requêtes plus longues et les autres modes de traitement ont des tarifs différents. Cent tâches suivant exactement ce profil d’utilisation coûteraient $30 en frais de base du modèle. Détail des tarifs de GPT-6.1 Sol.

La décision budgétaire consiste à déterminer si la personnalisation souhaitée justifie le travail nécessaire pour la maintenir. Pi supprime les frais de licence du socle de l’agent ; les dépenses liées au modèle, la vérification humaine et le temps de développement consacré à votre workflow restent à prévoir.

Personnaliser le workflow avec le strict nécessaire

Utilisez les instructions pour les conventions, les skills pour les procédures réutilisables et les extensions pour le comportement exécutable.

Le fichier SKILL.md d’une skill commence par un nom et une description. Pour charger explicitement une skill précise, appelez-la avec /skill:name. Les extensions s’exécutent dans le processus de Pi : examinez leur code avant de les charger. Skills, extensions.

La commande pi install ./local-package installe un package que vous avez préparé en local. Pour un package publié, utilisez pi install npm:@scope/package@version avec son nom et sa version réels. Ajoutez --local pour enregistrer sa déclaration au niveau du projet dans .pi/settings.json. Lancez /reload après avoir modifié les ressources pendant une session active. Documentation des packages.

Pour un service MCP externe, configurez son serveur et utilisez /mcp login <server> si OAuth est nécessaire. Ajoutez cette intégration dans un second temps, une fois la configuration de base opérationnelle. Documentation MCP.

Six usages classés par intérêt pratique

Le meilleur point de départ est un travail récurrent dans un dépôt que vous comprenez. Les workflows suivants sont des propositions : leur intérêt dépend de votre code et de la rigueur de vos vérifications.

1. Ajouter un test de non-régression pour un bug signalé. Un fondateur qui maintient une application web par abonnement pourrait joindre les étapes de reproduction du bug, l’implémentation et les tests, demander à Pi un test qui échoue puis une correction ciblée, et relancer les vérifications pertinentes. L’intérêt est de transformer le problème observé en test durable.
2. Relire une modification avant d’ouvrir une pull request. Un développeur pourrait fournir à Pi un diff local et une skill de revue propre au dépôt, puis demander les défauts potentiels, avec des références aux fichiers et des explications. Repérer un problème concret en amont pourrait éviter un aller-retour pendant la revue.
3. Migrer une partie bien délimitée d’une application. Un responsable de maintenance pourrait formaliser la procédure de migration dans une skill, l’appliquer à un module et lancer ses vérifications. Le gain potentiel vient de la réutilisation de la procédure sur des modules similaires, avec une revue de chaque diff.
4. Comprendre un dépôt inconnu. Un ingénieur qui rejoint le projet pourrait demander à Pi de suivre une requête depuis son point d’entrée jusqu’au stockage, puis conserver des notes avec les références aux fichiers et les commandes de vérification utiles. Ces notes pourraient réduire les questions répétitives lors de la prise en main.
5. Écrire un petit script de maintenance. Une personne chargée de jeux de données de test obsolètes pourrait demander à Pi de préparer un script, de l’essayer sur des exemples d’entrée et d’en documenter l’utilisation. Une fois vérifié, le script pourrait remplacer des modifications manuelles répétées.
6. Créer un workflow interne pour les développeurs. Un responsable technique pourrait regrouper une commande personnalisée et des skills dans un package, ou intégrer Pi avec le mode print pour des commandes ponctuelles, RPC pour piloter un processus distinct, ou la bibliothèque SDK pour intégrer des sessions à une application. L’intérêt est d’adapter l’agent à une tâche récurrente ; l’intégration et le support restent à la charge du responsable. Interfaces d’intégration.

La revue de code propre à un dépôt est la piste la plus prometteuse

Un package de revue avant fusion offre l’opportunité la plus claire : le travail se répète et l’acheteur connaît déjà le coût des retards de revue. Une petite équipe de développement pourrait payer pour un package maintenu qui vérifie ses propres conventions et fournit aux relecteurs des éléments concrets.

L’analyse de la demande a relevé 1,300 recherches Google mensuelles estimées aux États-Unis pour “ai code review”. CodeRabbit Essentials donne un repère tarifaire à $24 par développeur et par mois avec facturation annuelle, ou $30 avec facturation mensuelle. Ces données signalent un intérêt pour cette tâche et l’existence d’une catégorie payante ; elles n’établissent pas une demande pour un package Pi. Volume de recherche : aperçu des mots-clés DataForSEO, vérifié le 3 octobre 2026. Tarifs de CodeRabbit.

La version minimale commercialisable pourrait réunir une skill de revue, une commande qui récupère le diff local, des vérifications propres au dépôt et un rapport avec des références aux fichiers. Prévoyez d’abord une utilisation locale. La difficulté est de se différencier : un prompt générique se copie facilement, et un package Pi demande sa propre maintenance, des contrôles d’accès et du support. Ce qui se vend, c’est la qualité des vérifications du dépôt et leur suivi.

Un package de démarrage pour l’équipe constitue la deuxième piste. Un responsable de développement pourrait acheter la mise en place et la maintenance d’une configuration cohérente des fournisseurs, d’un AGENTS.md, de skills partagées et d’un petit ensemble d’extensions validées. L’analyse de la demande a relevé 1,600 recherches mensuelles estimées aux États-Unis pour “open source ai coding assistant”, mesurées par DataForSEO à la même date. Une première version pourrait se limiter à un package et à une procédure de prise en main pour les dépôts d’une équipe. La difficulté : l’intérêt dans les recherches ne prouve pas une volonté de payer pour l’installation ; la valeur durable doit venir de la maintenance du workflow de l’équipe.

Pi convient moins aux équipes qui veulent déléguer les choix de configuration

Choisissez un outil géré si votre équipe attend des demandes d’autorisation, de l’isolation et des workflows standardisés fournis dans un produit avec support. Les outils de Pi utilisent les autorisations du processus qui le lance. Le mécanisme de confiance du projet détermine quelles ressources du projet sont chargées, mais il n’isole pas les appels d’outils dans un bac à sable. Le répertoire de travail n’empêche pas les commandes d’atteindre d’autres chemins accessibles. Modèle de sécurité de Pi.

Des extensions peuvent ajouter des étapes de confirmation ou une protection des chemins, et un conteneur peut fournir une isolation au niveau du système d’exploitation. Ces choix demandent un travail d’implémentation et de maintenance à votre équipe. Le bac à sable JavaScript du codemode conserve lui aussi les autorisations des outils appelés. Possibilités des extensions, codemode.

Pi laisse également les sous-agents intégrés et le mode planification en dehors de son cœur. À mon avis, ce choix convient à un développeur qui veut façonner un socle léger, et moins à une équipe qui souhaite confier ces décisions à un tiers. Choix de conception du projet.

Lundi, confiez à Pi une tâche bien délimitée de correction de bug ou de test dans un dépôt que vous maintenez. Conservez le diff et le résultat des tests, puis choisissez quelle procédure récurrente mérite une skill. Si vous souhaitez faire développer un workflow sur mesure pour votre équipe, commencez par le développement d’agents IA.