Apprendre à travailler avec IBM Bob

La définition officielle

La page d'accueil de la documentation définit Bob comme un « AI SDLC partner » : un partenaire pour le cycle de vie du logiciel, qui vient s'ajouter à vos façons de travailler et vous aide à intervenir sur de vraies bases de code [D ide]. Le mot important est cycle de vie : la documentation ne vend pas un outil qui écrit des lignes à votre place, mais un outil qui intervient sur la compréhension, l'écriture, la revue, la documentation et l'automatisation.

Les usages annoncés sont au nombre de sept : générer du code, refactoriser et déboguer, écrire et mettre à jour la documentation, répondre à des questions, automatiser des tâches, créer des fichiers et des projets, et suivre sa consommation pour l'optimiser [D ide].

Un agent, pas une complétion

Un moteur de complétion propose la suite de la ligne que vous tapez. Il ne lit pas votre dépôt, ne lance pas vos tests, ne vous demande rien. Bob fonctionne autrement : il dispose d'outils et s'en sert. Il lit des fichiers, cherche dans le code, exécute des commandes dans le terminal, appelle des serveurs externes, et découpe le travail en sous-tâches [D ide/core-concepts/tools].

Cette capacité d'action est précisément ce qui impose un garde-fou : Bob demande votre approbation avant les actions sensibles, et vous pouvez décider à l'avance lesquelles sont automatiquement approuvées. C'est le sujet du niveau 2. Pour les sous-agents, la documentation est explicite : vous approuvez chaque lancement avant qu'il démarre [D ide].

Bob IDE et Bob Shell

Bob existe sous deux formes. Bob IDE est l'application graphique, celle de cette formation. Bob Shell apporte les mêmes capacités à la ligne de commande : sessions interactives, sessions non interactives pour l'automatisation, intégration dans le terminal d'un éditeur [D shell]. Les deux outils offrent « la même assistance, optimisée pour leur environnement respectif » [D llms.txt], et l'on retrouve dans les deux les trois mêmes modes. Bob Shell est traité au niveau 3, pour l'automatisation et l'intégration continue.

Ce qu'il faut avant de commencer

La documentation annonce une installation d'environ cinq minutes et demande : un système macOS, Linux ou Windows, 4 Go de mémoire vive au minimum et 8 Go recommandés, 500 Mo d'espace disque, et une connexion internet active [D ide/getting-started/install].

Installer

Le téléchargement se fait depuis bob.ibm.com/download. Sur Mac, il faut d'abord savoir quel processeur équipe la machine : menu Pomme, « About This Mac », ligne « Chip ». Une puce M1, M2 ou M3 appelle l'installateur mac-ARM ; un processeur Intel appelle l'installateur mac-Intel. On ouvre ensuite le fichier .pkg et on suit l'assistant. Sur Windows, on exécute le .exe, on garde le répertoire proposé par défaut, et on termine par « Finish » [D ide/getting-started/install].

Se connecter

Un IBMid est nécessaire. Tous les clients passent par le même point d'entrée, bob.ibm.com/login [D ide/account/signing-in]. Bob ouvre votre navigateur, vous saisissez votre adresse, Bob reconnaît le domaine et vous redirige soit vers IBMid, soit vers le système d'authentification unique de votre entreprise, puis vous ramène dans l'application. Il est possible de créer un IBMid à partir d'un compte Google. L'authentification unique par SAML ou OIDC demande un plan Enterprise.

Deux détails qui font perdre du temps si on les ignore : les sessions expirent après une période d'inactivité, et une session est propre à chaque client. Être connecté dans Bob IDE ne vous connecte pas dans Bob Shell.

Trois modes, trois niveaux de permission

La documentation annonce trois modes disponibles par défaut [D ide/features/modes]. Ce ne sont pas trois styles de réponse, mais trois jeux d'outils différents, donc trois niveaux de pouvoir sur votre projet.

Ask mode est en lecture seule : il lit, il explique, il ne modifie rien. Le guide de démarrage relie explicitement ce choix au principe du moindre privilège [D ide/getting-started/quickstart]. Agent mode est le mode complet : il lit, écrit et surtout c'est le seul à pouvoir exécuter des commandes dans le terminal. Plan mode se situe entre les deux, et sa position surprend souvent.

Changer de mode

Quatre façons de changer de mode sont documentées : le menu déroulant à gauche du champ de saisie, le raccourci cyclique Command + point sur macOS ou Ctrl + point ailleurs, l'acceptation d'une suggestion de Bob, et le changement que Bob opère de lui-même en cours de tâche, par exemple lorsqu'il passe de Plan à Agent une fois le plan prêt [D ide/features/modes]. Les commandes /agent, /plan et /ask font également le travail [D ide/getting-started/quickstart].

Trois questions suffisent

Les vidéos d'onboarding suivent un scénario simple et reproductible : un développeur arrive sur un projet qu'il ne connaît pas, et personne n'est disponible pour lui expliquer. Il pose trois questions, dans cet ordre : à quoi sert cette application, comment la démarrer, et comment elle est architecturée.

Un budget, pas une mémoire

Chaque tâche dispose d'une fenêtre de contexte plafonnée à 270 000 tokens [D ide/core-concepts/context-window-management]. La documentation insiste sur une formule utile : la fenêtre de contexte n'est pas un espace de stockage, c'est le budget de tokens actif à chaque étape.

Quand la conversation approche du plafond, une compaction se déclenche, généralement autour de 190 000 tokens. Elle conserve le récent et le pertinent, résume ou supprime l'ancien. La documentation prévient sans détour : la compaction perd de l'information. Environ 20 000 tokens sont par ailleurs réservés à la réponse du modèle.

Ce qui occupe la fenêtre

Le panneau détaille six postes : le system prompt, les définitions d'outils, les outils MCP, les Rules, les Skills et les Messages. Vos mentions de fichiers, les sorties de commandes et les résultats d'outils comptent tous dans Messages ; le contenu des fichiers n'apparaît pas sur une ligne séparée.

Sur le projet fil rouge, la documentation mesure une surcharge de départ d'environ 8 500 tokens avant même votre première vraie question. Le point décisif est ailleurs : Bob renvoie l'intégralité du contexte actif à chaque message. Une longue conversation coûte donc de plus en plus cher à chaque tour.

Les Bobcoins

La consommation se mesure en Bobcoins, des unités qui agrègent l'usage de ressources de calcul, tous modèles confondus [D ide/account/bobcoins]. Les tokens d'entrée comme de sortie comptent. Un Bobcoin vaut 0,50 dollar, un prix confirmé à deux endroits. Les allocations mensuelles documentées sont de 50 Bobcoins pour l'essai gratuit et le plan Pro, 180 pour Pro+, et 1 000 pour Ultra.

Le lien avec le chapitre précédent est direct, et c'est l'argument économique de la formation : puisque chaque message renvoie tout le contexte actif, une conversation qui traîne coûte plus cher à chaque tour. Ouvrir une nouvelle tâche quand on change de sujet n'est pas une coquetterie d'organisation, c'est une économie.

Cinq étapes

La vidéo 2 résume la méthode qu'on retrouve dans tous les tutoriels : donner le contexte, faire produire un plan, itérer sur le plan, implémenter, puis itérer sur l'implémentation. Le présentateur qualifie l'étape du plan de plus importante, et décrit l'implémentation comme « étonnamment peu spectaculaire » quand le plan est bon [V02].

Cadrer avant de demander

Le tutoriel sur les fonctionnalités complexes fait précéder le prompt de quatre questions, à se poser avant de toucher au clavier [D ide/tutorials/create-a-plan-and-implement-complex-features] : que fait la fonctionnalité, et surtout que ne fait-elle pas ? Quelles couches touche-t-elle, interface, service, base de données ? Quelles contraintes s'imposent, par exemple le nombre de fichiers ou la rétrocompatibilité ? Et à quoi reconnaîtra-t-on que c'est terminé ?

Ces quatre réponses se transposent directement en un prompt structuré en quatre blocs : ce que je veux, le périmètre, les contraintes, la définition de « terminé ». C'est le modèle à réutiliser pour toutes vos demandes de plan.

Faire écrire le plan dans un fichier

Un plan qui reste dans la conversation disparaît avec elle. La vidéo 2 en fait une consigne : toujours sauvegarder le plan dans un fichier pour pouvoir l'itérer [V02]. Le tutoriel obtient ce résultat en le demandant explicitement dans les contraintes, par exemple un dossier plans et au plus trois fichiers.

Relire le plan, vraiment

C'est ici que la vidéo 2 place la phrase la plus utile de toute la playlist : c'est le moment d'« utiliser son propre cerveau » [V02]. Trois critères de relecture sont proposés par le tutoriel.

• Le périmètre correspond-il à ce que vous avez demandé, ni plus, ni moins ?
• Traquez le vague. Des formules comme « ajouter au besoin » ou « mettre à jour de façon appropriée » sont des trous dans le plan, pas des détails de rédaction.
• Chaque étape nomme-t-elle ses fichiers ? Une étape sans fichier identifié est une étape que personne ne peut vérifier.

Puis on corrige, dans la même conversation Plan, par une demande ciblée. Le tutoriel donne un exemple de correction portant sur des couleurs précises à associer à chaque classe de siège.

Implémenter dans une tâche neuve

Une fois le plan approuvé, on ouvre une nouvelle tâche avant d'implémenter. Le tutoriel donne trois raisons : la discussion de planification ne pèse plus sur le budget de tokens, le contexte se recentre sur le plan approuvé, et l'on évite de mélanger réflexion et exécution. Le prompt d'implémentation tient alors en une ligne, avec une mention du dossier de plans.

Build the features in the plans folder
@plans/

Les mentions de contexte

Une mention commence par @ et ouvre un menu. Sept types sont documentés [D ide/features/context-mentions].

Précis plutôt que large

La documentation oppose deux prompts pour illustrer la différence entre viser et ratisser [D ide/core-concepts/context-window-management].

# Précis : Bob lit 23 lignes et répond
@/src/utils/validation.ts:45-67 Fix the email validation logic

# Trop large : Bob remplit sa fenêtre et répond vaguement
@/src @/tests @/docs Review everything and suggest improvements

Sur un gros projet, la page dédiée conseille aussi d'utiliser les outils de symboles plutôt que de mentionner un fichier entier : demander la liste des fonctions d'un fichier, puis n'agir que sur celle qui vous intéresse [D ide/core-concepts/large-projects].

Appeler Bob depuis l'éditeur

Les code actions évitent de décrire au clavier ce que vous avez sous les yeux : elles transmettent automatiquement le chemin et les numéros de ligne [D ide/features/code-actions]. On les atteint par l'ampoule dans la gouttière, par le clic droit au sous-menu « Bob », ou par la palette de commandes. Deux raccourcis valent la peine d'être retenus : Cmd ou Ctrl + K ouvre une conversation en ligne à l'endroit du curseur, Cmd ou Ctrl + L envoie la sélection au panneau de conversation.

Un contexte permanent avec /init

La commande /init fait analyser le projet par Bob et produit un fichier AGENTS.md à la racine, plus un jeu de règles par mode dans .bob/ [D ide/tutorials/start-a-project]. Ce fichier est rechargé à chaque conversation : il évite de réexpliquer le projet à chaque fois. La contrepartie est qu'il occupe du contexte en permanence, d'où le conseil répété de le garder court et opérationnel, limité aux commandes d'installation, de test et de style.

Quand le contexte s'empoisonne

La documentation consacre une page entière à un phénomène qui surprend les débutants : une information fausse ou hors sujet entrée dans la conversation y reste et continue d'être renvoyée à chaque message [D ide/core-concepts/context-poisoning]. La phrase clé mérite d'être citée : Bob n'ignore pas de façon fiable un texte plausible simplement parce qu'il est faux.

Les symptômes sont reconnaissables : les réponses se dégradent, Bob se trompe d'outil, un travail en plusieurs étapes tourne en rond, les corrections ne tiennent pas. Les causes principales sont un fait erroné énoncé plus tôt, une documentation obsolète dans le dépôt, un collage trop volumineux, ou une compaction dont le résumé a fini par remplacer l'original.

Le réflexe correctif est contre-intuitif : ne corrigez pas par de nouvelles instructions, cela masque le problème un ou deux échanges. Ouvrez une nouvelle tâche. Elle vide les messages empoisonnés tout en conservant vos règles et vos fichiers sur le disque. La page ajoute une règle de départage utile en cas de contradiction entre un commentaire et le code : faites confiance aux tests plutôt qu'au texte.

Le mécanisme

Par défaut, Bob demande avant d'agir, une action à la fois. Les contenus volumineux, comme un diff complet, sont repliés dans un aperçu. Surtout, une commande est modifiable avant d'être approuvée : vous pouvez corriger ce que Bob s'apprête à lancer [D ide/features/auto-approving-actions].

S'y ajoutent les approbations au niveau de la tâche, ces boutons « Approve … tools for task » que vous avez déjà rencontrés : ils ouvrent un groupe d'outils pour la tâche en cours seulement. Pour l'exécution de commandes, un écran supplémentaire demande de confirmer que vous comprenez les risques.

Neuf groupes, trois niveaux de risque

Le panneau des permissions liste neuf catégories, chacune avec un niveau de risque documenté. Edit et Execute sont classés à risque élevé, la première parce qu'elle crée, modifie et supprime des fichiers, la seconde parce qu'elle lance des commandes. Read et Skill sont à risque moyen, MCP entre moyen et élevé. Les quatre dernières, Todo, Subtask, Subagent et Mode, sont à risque faible.

Revenir en arrière

Bob prend des instantanés des fichiers pendant une tâche : au démarrage, puis avant chaque modification [D ide/features/rollback]. La vidéo 10 parle de « points de reprise » créés à chaque écriture, et décrit le retour comme un retour à la dernière configuration correcte connue [V10]. Les deux vocabulaires désignent visiblement le même mécanisme, mais aucune source ne l'affirme.

La restauration se fait à deux granularités : en survolant un de vos messages dans la conversation, pour revenir à l'état d'avant ce message ; ou fichier par fichier depuis la vue des fichiers modifiés. Dans ce second cas, Bob est informé que vous avez annulé un fichier.

La page des bonnes pratiques en tire un conseil stratégique qui rejoint le chapitre précédent : si Bob produit un travail médiocre, revenez en arrière plutôt que de corriger par de nouvelles instructions [D ide/getting-started/best-practices]. Corriger laisse le mauvais contenu dans la conversation. Elle rappelle aussi que Git reste le vrai filet de sécurité.

Un contexte isolé, un résumé en retour

Un sous-agent est un agent indépendant, lancé par Bob pour une tâche autonome, avec sa propre fenêtre de contexte, et qui ne renvoie qu'un résumé [D ide/features/subagents]. L'isolation est stricte : il ne partage ni état, ni fichiers, ni résultats d'outils avec Bob, sauf si Bob les lui transmet explicitement dans la description de la tâche.

C'est tout l'intérêt : la lecture de vingt fichiers consomme la fenêtre du sous-agent, pas la vôtre. La conversation principale ne reçoit que la conclusion et reste utilisable plus longtemps [V02].

Un point de contrôle important : vous approuvez chaque lancement avant qu'il démarre, et Bob attend votre confirmation.

Deux types, deux usages

Le type explore est en lecture seule et utilise un modèle plus léger : recherche, résumé, compréhension d'une structure. Le type general a l'accès complet, y compris l'écriture et les commandes. La documentation ne nomme pas les modèles correspondants. Par défaut l'historique de la conversation n'est pas transmis ; une option permet de le faire.

Les modes encadrent ce qui est permis : Agent autorise tous les types, Plan et Ask se limitent à explore. Si un mode interdit les sous-agents, Bob fait simplement le travail lui-même, sans échouer.

Sous-agent ou sous-tâche ?

La confusion est fréquente. Un sous-agent travaille en silence, en arrière-plan, sans interaction possible, et rend un résumé. Une sous-tâche est visible, interactive, et ouvre un fil qu'on peut suivre. Le premier sert à collecter sans polluer, la seconde à mener un travail complexe en gardant la main.

Quand plusieurs sous-agents tournent, un panneau repliable les regroupe et affiche le nombre de terminés sur le total, le nombre d'outils utilisés, le cumul des tokens, du coût et du temps écoulé, ainsi que les appels d'outils en échec. Chaque entrée se déplie jusqu'aux appels individuels.

Configurer un espace de travail sûr

La page de recommandations de sécurité tient en cinq points [D ide/security/bob-security-guidance] : configurer .bobignore, limiter l'auto-approbation, garder les secrets hors des prompts et des fichiers accessibles, n'utiliser que des serveurs externes authentifiés et contrôlés, et relire les sorties de Bob avant de les appliquer.

L'exemple de .bobignore donné par la documentation vise directement les secrets.

.env
secrets/
*.key
config/credentials.json

Deux limites sont énoncées sans détour : .bobignore ne vaut que pour l'espace de travail courant, et ce n'est pas un bac à sable système. Combiné à ce que vous avez vu au chapitre 7, où une mention explicite passe outre, cela donne la règle prudente : un secret qui compte ne doit pas se trouver dans le projet.

Relire avant de faire relire

La vidéo 11 pose le problème : la relecture par un collègue reste précieuse pour le partage de connaissances, mais elle devient un goulet d'étranglement. D'où l'idée d'un premier niveau de revue dans l'éditeur [V11]. La commande /review déclenche l'analyse ; Bob examine le diff et les fichiers complets, puis rend des constats classés.

Les critères examinés sont énoncés dans la vidéo : cas limites, sécurité, accessibilité, couverture de tests et conventions du projet. Chaque constat porte une explication, un lien vers l'emplacement exact, et une action pour approfondir dans la conversation. Une fois corrigé, un constat passe à l'état résolu.

Le message de commit

Deux chemins mènent au même résultat. Par l'interface, une icône en forme d'étincelle à côté de la zone de message génère une proposition, et un second clic en donne une autre [D ide/features/commit-messages]. Bob s'appuie sur trois sources : les changements, le nom de la branche, et l'historique récent pour respecter le style du projet. D'où un conseil concret : mettez le numéro de l'issue dans le nom de branche, Bob le reprendra.

Par la conversation, on demande simplement le commit. La vidéo 3 relève un comportement appréciable : Bob a commité le code sans inclure les documents de planification [V03].

La pull request

Il faut des changements commités sur une branche et le droit de pousser. Trois points d'entrée existent : l'icône dans le panneau de contrôle de version, la palette de commandes, ou la commande /create-pr [D ide/features/pull-requests]. Bob propose les trois branches de base les plus probables, puis un titre et une description que vous pouvez faire réécrire autant de fois que nécessaire.

Détail qui fait gagner du temps en équipe : Bob cherche automatiquement un modèle de pull request dans six emplacements conventionnels, dont .github/pull_request_template.md. S'il en trouve plusieurs, il demande lequel utiliser.

Où vivent les règles

La documentation donne des chemins précis, et c'est la portée qui décide du chemin [D ide/configuration/rules].

Il n'y a ni schéma ni en-tête à respecter : du Markdown ou du texte (.md, .txt). Les noms de fichiers cités par la documentation donnent le ton : coding-style.md, typescript.md, security.md, ou numérotés 01-style-guide.md et 02-formatting.txt quand l'ordre compte.

mkdir -p .bob/rules && echo "# Project standards" > .bob/rules/coding-style.md

Comment Bob les charge

Le comportement documenté est mécanique, et vaut la peine d'être connu précisément : lecture récursive des dossiers, fichiers traités dans l'ordre alphabétique — d'où la numérotation. Les fichiers vides sont ignorés, les liens symboliques suivis jusqu'à une profondeur de 5, et certains noms sont exclus d'office : .DS_Store, *.bak, *.cache, *.log, *.tmp, Thumbs.db.

La phrase la plus importante de la page est celle-ci : les règles sont injectées dans chaque conversation et dans tous les modes, et « un mode ne peut pas contourner une règle ». C'est ce qui distingue une règle d'une consigne de mode : la règle est un plancher, pas une option.

L'ordre de priorité documenté : le global (~/.bob/rules/) est chargé, puis le workspace (.bob/rules/) ; le workspace peut écraser le global. À l'intérieur d'un niveau, les règles de mode sont chargées avant les règles générales, et AGENTS.md se place entre les deux — après les règles de mode, avant les règles générales du workspace.

Un exemple conforme, et ce qu'il révèle

Le tutoriel « Standardize Bob's behavior » donne le contenu intégral d'un .bob/rules/basic_rules.md de trois règles [D ide/tutorials/standardize-bobs-behavior].

Always include concise JSDoc strings for every public function.
Be very concise in your wording.
Write a summary of every interaction into the folder `internal-monologue/`.
Name the file starting with a timestamp, followed by a concise description of the interaction.
Example: 2026-01-15_update-readme.md

Les trois règles ne jouent pas du tout dans le même registre, et c'est instructif : la première est un standard de documentation (une contrainte sur le code produit), la deuxième un style de communication (une contrainte sur les réponses), la troisième un journal persistant — un « monologue interne » qui donne une piste d'audit, une continuité entre sessions et une transparence vis-à-vis de l'équipe. Une règle peut donc porter sur le code, sur le dialogue, ou sur la trace laissée.

Doc · Tutoriel

Doc · Tutoriel

Partager, et payer le prix

Pour standardiser une équipe, la documentation propose trois approches : commiter .bob/rules/ (git add .bob/rules/) pour que la règle suive le dépôt ; cloner un dépôt de règles d'organisation dans ~/.bob/rules/ ; ou une approche hybride — l'organisation en global, le projet en workspace, sachant que le workspace l'emporte.

Reste le coût. Une règle est rechargée à chaque conversation, donc elle occupe une part fixe de vos 270 000 tokens, quoi que vous fassiez. La mesure de la vidéo 4 donne l'ordre de grandeur : 150 lignes ≈ 2 700 tokens, soit environ 1 % de la fenêtre. Ce n'est pas énorme, mais c'est permanent — et c'est précisément pour cette raison que la fonctionnalité suivante existe.

Deux réglages à connaître : AGENTS.md peut être désactivé avec "bob-code.useAgentRules": false côté IDE, "bob-shell.useAgentRules": false côté Shell.

Le format : YAML, et dix groupes d'outils

Le format documenté est le YAML. Le JSON historique (custom_modes.json) est encore accepté mais migré automatiquement : le fichier global est converti au démarrage, le fichier projet lors d'une édition via l'interface [D ide/configuration/custom-modes].

Les dix groupes d'outils côté IDE : read, edit (restreignable), execute, mcp, skill, workflow, todo, subtask, subagent, mode. Vous reconnaissez les neuf groupes de permissions du chapitre 8, plus workflow.

La restriction qui n'existe qu'en YAML

Le groupe edit accepte un fileRegex, et c'est le mécanisme du « deployment engineer » de la vidéo. Voici l'exemple complet de la documentation.

customModes:
  - slug: docs-writer
    name: 📝 Documentation Writer
    description: Writes and revises Markdown documentation.
    roleDefinition: You are a technical writer specializing in clear documentation.
    whenToUse: Use this mode for writing and editing documentation.
    customInstructions: Focus on clarity and completeness in documentation.
    groups:
      - read
      - - edit
        - fileRegex: ".*\\.(md|mdx)$"
          description: Markdown files only
      - skill

Notez la structure : le groupe edit restreint devient une liste à deux éléments — le nom du groupe, puis un objet de contrainte. C'est la partie de la syntaxe qui surprend le plus.

Les motifs cités par la documentation couvrent les cas courants : .*\.md$, ^src/.*, .*\.(css|scss)$, et le plus utile, ^(?!.*(test|spec)).*\.(js|ts)$ — tout le JavaScript et le TypeScript sauf les tests. La documentation suggère elle-même de demander à Bob de générer ces expressions.

Chemins et priorité

La priorité côté IDE est simple : projet > global > défaut. Côté Bob Shell, la chaîne est plus longue : CLI > projet > global > modes système > défauts.

Doc · Tutoriel

Doc · Tutoriel

La documentation décrit trois parcours différents pour créer un mode par l'interface, selon la page consultée : Settings → onglet Modes → bouton de création ; sélecteur de modes → engrenage → + ; ou trois points de la barre latérale → Modes → Edit. Les trois mènent au même formulaire.

Le format, et le champ qui décide de tout

Un skill est un dossier contenant un SKILL.md : un front matter YAML, puis les instructions en Markdown [D ide/features/skills].

---
name: code-review
description: Review code for bugs, security issues, and best practices
---

When reviewing code, check for:
- Security vulnerabilities
- Performance issues
- Missing error handling at API boundaries
- Unused imports and dead code

Provide a summary with severity levels for each finding.

Deux champs seulement sont requis, et le second porte tout le poids. name est le nom affiché et le nom d'invocation (/code-review). description est ce que Bob lit pour décider d'activer le skill sans qu'on le lui demande — et la documentation est catégorique : « skills without descriptions are ignored ». Un skill sans description n'est pas un skill dégradé, il n'existe pas.

D'où le conseil de rédaction de la documentation, qui oppose deux formulations : « Review code for bugs, security issues, and best practices » est une bonne description, parce qu'elle contient les mots que l'utilisateur emploiera. « Code review skill » est une mauvaise description, parce qu'elle ne décrit rien. Un troisième champ apparaît dans le tutoriel : user-invocable: true, qui autorise l'appel explicite par /<nom>.

À nom égal, le skill de projet l'emporte sur le global. Le dossier peut contenir des fichiers d'appui — la documentation cite checklist.md, severity-guide.md, analyze.sh, report-generator.py — que Bob lit automatiquement une fois le skill activé. C'est le mécanisme qui permet à un skill court d'ouvrir sur un corpus long.

Règle, mode ou skill ?

Vous avez maintenant les trois. Le choix se fait sur deux questions : ce texte doit-il être là toujours, et doit-il empêcher quelque chose ?

Activation et approbation

Trois chemins d'invocation : explicite avec /<skill-name>, par le sélecteur $ en Bob Shell, ou implicite quand Bob reconnaît la correspondance avec la description. Pour créer : la commande /create-skill dans le chat, ou Bob Settings → Skills → +. Les skills sont chargés une seule fois par conversation, pour éviter de dupliquer le prompt.

Par défaut, Bob demande votre permission avant d'activer un skill. On peut la retirer par Bob Settings → Auto-Approve → Skills, ou côté Shell par "autoApprove": { "skills": true }.

Non documenté : aucune limite de taille pour un SKILL.md, aucune indication de langue, et l'emplacement des skills fournis par Bob lui-même (comme create-plan, utilisé en mode Plan) n'est nulle part précisé.

Une commande, c'est un nom de fichier

Le mécanisme est d'une simplicité désarmante : vous déposez un fichier Markdown dans .bob/commands/ (projet) ou ~/.bob/commands/ (global), et le nom du fichier devient la commande [D ide/features/slash-commands]. review.md donne /review, test-api.md donne /test-api, deploy-check.md donne /deploy-check.

Le corps du fichier est le prompt, avec des arguments positionnels $1, $2. Un front matter optionnel améliore l'ergonomie : description s'affiche dans le menu, argument-hint affiche une indication grise sur les arguments attendus.

---
description: Create a new API endpoint
---
Create a new API endpoint called $1 that handles $2 requests.
Include proper error handling and documentation.

À nom égal, le projet l'emporte sur le global. Une protection est explicite : les commandes de mode (/agent, /plan, /ask, /<slug>) ne peuvent pas être surchargées. En revanche — et c'est un manque de la documentation — rien ne dit si une commande personnalisée peut surcharger une commande intégrée comme /review. Le nom de fichier review.md figure pourtant dans les exemples officiels. Testez avant de compter dessus.

Les commandes intégrées documentées côté IDE sont peu nombreuses et vous en connaissez déjà l'essentiel : /init (crée .bob et les AGENTS.md), /review avec ses variantes (/review <branche>, /review #<n> --issue-coverage), /create-pr, /create-skill. Bob Shell en ajoute une longue série propre au terminal — /compact, /hooks, /permissions, /resume, /mcp, /manage-secrets, /skills, /status, /logs — que vous retrouverez dans l'aide-mémoire.

Les hooks : cinq événements côté IDE, sept côté Shell

Un hook est une commande shell que Bob exécute à un moment donné, avec un payload JSON sur l'entrée standard [D ide/configuration/lifecycle-hooks].

Bob Shell ajoute PreCompact (bloquant) et PostCompact, apparus en version 2.0.3. Deux hooks ont donc un pouvoir particulier : SessionStart et UserPromptSubmit, dont la sortie standard devient du contexte. C'est le moyen documenté d'injecter automatiquement l'état du dépôt — branche courante, version de Node, nom du projet — au début de chaque session.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "^write_file$",
        "hooks": [
          { "type": "command", "command": "sh .bob/hooks/check.sh", "timeout": 5 }
        ]
      }
    ]
  }
}

Le matcher est une expression régulière sur le nom de l'outil, et ne s'applique qu'à PreToolUse et PostToolUse ; omis, il attrape tous les outils. Le timeout est en secondes, 10 par défaut, 0 pour illimité. Le type "command" est le seul accepté côté IDE ; Bob Shell accepte en plus "https", qui appelle une URL.

Les codes de sortie portent toute la sémantique : 0 pour un succès, 2 pour bloquer l'action, et n'importe quel autre code non nul pour un échec non bloquant, journalisé puis ignoré. Un hook qui plante ne vous arrête donc pas — seul un exit 2 délibéré le fait.

Les emplacements suivent la logique habituelle, avec une nuance : ~/.bob/settings/settings.json pour le global, .bob/settings.json pour le workspace, et les hooks globaux s'exécutent toujours, les hooks du workspace étant fusionnés par-dessus.

Côté gouvernance, l'onglet Hooks des réglages (IDE 2.1.0) liste les hooks globaux et workspace avec leur type d'événement, leur matcher, leur portée et leur état, et permet de les activer individuellement ; l'équivalent en Bob Shell est /hooks. Une politique d'entreprise EnforcedHooks permet à un administrateur d'imposer des hooks exécutés avant tout hook utilisateur et non modifiables.

Les limites explicites de la page : pas de hooks planifiés, pas de réécriture de l'entrée, pas de blocage depuis PostToolUse ni Stop.

Deux niveaux, et un troisième pour les administrateurs

Toute la configuration de Bob se répartit entre deux emplacements. Le global, dans ~/.bob/, s'applique à tous vos projets. Le projet, dans .bob/ à la racine du dépôt, ne vaut que pour lui et se versionne avec le code, ce qui en fait le support du partage en équipe.

S'y ajoute, sur Bob IDE uniquement, un niveau système réservé aux administrateurs, par préférences gérées sur macOS, par le registre sur Windows, et par /etc/bob/policy.json sur Linux. Quatre politiques existent, dont celle qui désactive des groupes d'auto-approbation et celle qui impose des hooks. Elles priment sur tout et verrouillent le réglage dans l'interface [D ide/security/group-policies].

Qui gagne en cas de conflit

C'est la question qui fait perdre le plus de temps quand une règle « ne s'applique pas ». Les ordres documentés sont les suivants.

• Modes : projet, puis global, puis les modes par défaut. Réutiliser le slug d'un mode intégré le surcharge.
• Règles : le global est chargé, puis le workspace, qui peut le surcharger. Dans chaque niveau, les règles de mode se chargent avant les règles générales, et AGENTS.md se place entre les deux.
• Serveurs MCP et skills : le projet prime sur le global à nom identique.
• Hooks : les globaux s'exécutent toujours, ceux du workspace sont fusionnés par-dessus.
• Commandes slash : projet avant global, et les commandes de mode ne sont jamais surchargeables.

Ce que Bob ne doit pas lire

Le fichier .bobignore, à la racine du workspace, utilise exactement la syntaxe de .gitignore [D ide/configuration/bobignore]. Il est lui-même toujours implicitement ignoré, ce qui empêche Bob de modifier ses propres règles d'accès.

.env
secrets/
*.key
config/credentials.json
*password*
*credential*
*apikey*
node_modules/
dist/
*.log

L'application est stricte en lecture comme en écriture pour les outils principaux, et list_files masque les fichiers ignorés ou les marque d'un cadenas. Quand Bob se heurte à un fichier interdit, il reçoit un message explicite lui demandant de continuer sans ce fichier ou de vous demander de modifier la liste.

Un port universel

MCP, pour Model Context Protocol, est un protocole standardisé que la documentation compare à un port USB-C [D ide/configuration/mcp/understanding-mcp]. L'architecture est client-serveur : Bob est le client, et les serveurs exposent des capacités, qu'il s'agisse de fichiers, d'une base de données ou d'une interface de programmation. Les échanges se font en JSON-RPC 2.0.

L'intérêt est d'étendre Bob sans toucher à son cœur, et de ne charger les capacités que lorsqu'elles servent. Un point à savoir avant de chercher : aucun serveur MCP n'est pré-installé.

Trois transports, deux à retenir

L'authentification déléguée

Pour les serveurs qui exigent un accès à votre compte, par exemple un service d'hébergement de code, Bob gère OAuth 2.1 automatiquement. Vous ajoutez le serveur sans en-tête ni variable d'environnement, Bob détecte les métadonnées d'autorisation à la première connexion, ouvre votre navigateur, puis stocke et rafraîchit les jetons [D ide/configuration/mcp/mcp-oauth].

Un piège à connaître, car il produit une panne silencieuse : un en-tête Authorization statique désactive complètement OAuth, et inversement, quand OAuth est actif, Bob retire cet en-tête. La documentation le dit en une phrase : n'utilisez qu'une seule méthode. Pour changer de compte, le redémarrage ne suffit pas, il faut le bouton de réinitialisation de l'authentification.

Gouverner ce qu'on branche

Chaque serveur ajoute ses définitions d'outils à la fenêtre de contexte, à chaque message. D'où une recommandation déjà vue au niveau 1 et confirmée ici : n'activez que les outils utiles, serveur par serveur et outil par outil, et préférez une configuration de projet à une configuration globale.

Deux réglages commandent l'ensemble : un interrupteur général d'usage des serveurs MCP, qui retire toute la logique du system prompt quand il est éteint, et un second qui autorise ou non Bob à écrire des serveurs MCP. Pour auto-approuver un outil MCP, il faut deux réglages à la fois : l'option globale dans les permissions, et l'autorisation permanente à côté de l'outil concerné.

Le principe

Le Literate Coding consiste à écrire des instructions en langage naturel, ou en pseudocode, directement dans le fichier source, puis à les faire remplacer par du code. Les instructions apparaissent surlignées en bleu. La génération analyse tout le fichier, comprend le contexte existant, remplace les instructions et présente un diff en ligne [D ide/features/literate-coding].

Plusieurs instructions dispersées dans le même fichier sont toutes prises en compte, où qu'elles se trouvent.

Les gestes

1. Activer : Cmd + I sur macOS, Ctrl + I ailleurs, ou l'icône en forme de baguette magique de la barre d'outils. Le tutoriel décrit une troisième voie, par le menu en points de suspension sur la ligne visée.
2. Écrire l'instruction en langage naturel.
3. Générer : Cmd + Entrée, ou le bouton de génération.
4. Accepter tout, ou rejeter avec Cmd + Maj + Retour arrière.

Installer et authentifier

Bob Shell demande Node.js 24 ou supérieur, et fonctionne sur macOS, Linux, Windows, ainsi que sur z/OS et Linux sur IBM Z [D shell/getting-started/install-and-setup]. Un détail qui déroute au premier usage : le paquet s'appelle bobshell, la commande s'appelle bob.

Pour un usage interactif, l'authentification passe par le navigateur, comme dans l'IDE. Pour l'automatisation, il faut une clé d'API de portée « Inference », dont la valeur n'est affichée qu'une seule fois, exposée dans une variable d'environnement.

export BOB_API_KEY="votre-cle-api"
echo 'export BOB_API_KEY="votre-cle-api"' >> ~/.bashrc

La variable exacte est BOB_API_KEY. La documentation se contredit sur un point qu'elle signale elle-même : la page consacrée à l'intégration avec les éditeurs cite BOBSHELL_API_KEY.

Deux modes de session

bob chat ouvre une session interactive. On y retrouve les mentions avec @, le sélecteur de skills, le menu des commandes, et un dialogue d'approbation à quatre réponses : approuver une fois, approuver le groupe d'outils pour la tâche, toujours autoriser une commande précise, ou refuser. Le pied de page affiche le mode, le contexte consommé et le coût en Bobcoins.

bob run exécute une session non interactive, acceptant un prompt en argument ou sur l'entrée standard, avec trois formats de sortie dont un JSON structuré et un flux d'événements.

Trois garde-fous pour l'intégration continue

Puisque l'approbation disparaît, la documentation propose de borner l'exécution sur trois axes : le coût, le nombre de tours, et les groupes d'outils autorisés. Désactiver l'édition, l'exécution et MCP donne un agent en lecture seule, ce qui est le bon réglage pour une revue automatisée.

export BOB_API_KEY=...
bob run --accept-license --trust --format json --max-cost 1 --max-turns 15 \
  --disable-tool-groups edit,execute,mcp "Review @src/ and list risks" > review.json
jq -r '.status, .last_message' review.json

Le format JSON renvoie un objet final contenant le statut, le dernier message et des statistiques : identifiant de tâche, jetons consommés en entrée et en sortie, durée, coût de session et nombre d'appels d'outils. C'est ce qui rend le résultat exploitable par un script.

Les dossiers de confiance

Sur un agent d'intégration continue, un point mérite attention. Les hooks globaux s'exécutent dans tout dossier qui n'est pas explicitement marqué comme non fiable, y compris un dépôt cloné pour la première fois. Le mécanisme des dossiers de confiance, désactivé par défaut, permet de déclarer une confiance par dossier ou par dossier parent, et c'est le seul moyen d'empêcher cette exécution.

La documentation formule la recommandation de façon frappante : relisez les hooks globaux et le fichier de réglages de chaque dépôt comme vous reliriez un fichier de construction ou une configuration d'intégration continue.

Mesurer : trois indicateurs

Bobalytics est réservé au plan Enterprise et s'atteint depuis la console d'administration [D ide/features/bobalytics]. Trois indicateurs structurent les tableaux de bord, et leurs définitions exactes méritent d'être lues, car elles ne sont pas intuitives.

Les identifiants sont anonymisés dans les tableaux de bord, et les administrateurs n'accèdent pas aux données individuelles. Un export produit une archive contenant un fichier par table.

La télémétrie

Elle est activée par défaut et désactivable à tout moment dans les réglages généraux [D ide/configuration/telemetry-data]. Ce qui est collecté : les actions, les fonctionnalités et performances, les erreurs et diagnostics. Ce qui ne l'est pas, formulé explicitement par la documentation : ni le code, ni le contenu des prompts, ni les fichiers.

Le cadre d'entreprise, en survol

Ce bloc est donné sans travail pratique, conformément au périmètre de la formation. Les points à connaître : une instance se provisionne par région, et quatre régions existent, aux États-Unis, en Europe, en Inde et au Japon. Les identités se raccordent par SAML ou OpenID Connect, avec vérification du domaine par enregistrement DNS. Les équipes portent chacune un budget de Bobcoins. Le journal d'activité est téléchargeable par tranches horaires dans un format d'audit normalisé.

Deux limites utiles à retenir. D'abord, quelle que soit la région choisie, les données de compte, de facturation et de gestion des utilisateurs restent aux États-Unis, et le domaine d'authentification américain doit être joignable depuis tous les réseaux. Ensuite, le journal d'activité ne contient pas les actions des utilisateurs, ni leurs prompts ni leurs appels d'outils : pour cela, la documentation renvoie aux hooks du chapitre 15.

L'intégration avec un système de supervision de sécurité n'est pas en libre-service : elle passe par une demande au support avec les paramètres du collecteur.

Les paquets premium

Trois extensions optionnelles étendent Bob à des plateformes particulières, installées comme extensions après vérification automatique des droits. Java Modernization propose des workflows guidés de montée de version et de migration. Bob for Z couvre la modernisation sur mainframe, avec documentation et refactorisation de programmes COBOL, PL/I ou Assembler. Bob for i est le plus fourni, avec deux modes propres, des dizaines de skills et un accès au système IBM i. Aucun prix n'est indiqué dans la documentation.

Lire le changelog pour ne pas travailler sur des souvenirs

C'est la compétence qui vous servira le plus longtemps. Les versions de référence au moment de la lecture des sources sont Bob IDE 2.1.0, d'août 2026, et Bob Shell 2.0.4, de septembre 2026 [D ide/changelog]. Les deux produits ont des numérotations distinctes.

Cette formation vous a signalé au fil des chapitres plusieurs écarts entre ce que montrent les vidéos et ce que dit la documentation. Le changelog les explique tous.

Dépannage : les quatre pannes les plus fréquentes

• Connexion impossible. Cause habituelle, un pare-feu. Il faut autoriser en HTTPS les domaines de Bob, dont le domaine d'authentification américain, quelle que soit votre région.
• Lenteurs après installation sur Mac. Presque toujours le mauvais installateur pour le processeur. Vérifiez la puce, désinstallez, réinstallez la bonne variante.
• Panneau de Bob disparu. Il a été sorti de sa zone. On le récupère par les réglages d'apparence de la barre latérale secondaire.
• En dernier recours, une réinitialisation complète existe. Exportez vos réglages avant, car l'opération est irréversible, et sachez que la documentation ne décrit aucune procédure de réimport du fichier exporté.

Concernant la foire aux questions, un avertissement de méthode : les pages ont été capturées avec leurs rubriques mais sans le texte des questions, replié à la capture. Cette formation ne les utilise donc pas, plutôt que d'en inventer le contenu.

Raccourcis clavier

Mentions de contexte

Commandes slash

Où vit la configuration

Les chiffres à connaître

Les équivalents français proviennent des vingt-quatre pages de la documentation française d'IBM téléchargées le 20 septembre 2026. Quand IBM conserve le terme anglais, c'est indiqué : cela signifie qu'il faut le garder, y compris à l'oral.

Deux sources de natures différentes ont été recoupées. Les vidéos montrent des gestes, dans un ordre, avec un résultat, mais datent de deux campagnes distinctes, octobre 2025 et juillet 2026. La documentation précise les options, les limites et les chiffres, et a été lue le 20 septembre 2026. Quand les deux divergent, le chapitre 20 explique comment trancher.

Les vidéos ne sont pas intégrées à cette page, seulement liées. Leurs transcriptions ne sont pas reproduites : elles sont automatiques, donc imparfaites, et ont servi de matière de travail, jamais de citation littérale.

Pour aller plus loin

• La documentation de Bob IDE et celle de Bob Shell, à relire après cette formation : vous y verrez des choses qui vous auraient échappé avant.
• Les changelogs, à consulter à chaque mise à jour. C'est l'habitude la plus utile que peut prendre un utilisateur d'agent de code.
• La playlist « Your Agentic AI Coding Partner », désormais lisible avec un œil critique sur ce qui a changé depuis.
• Le projet Galaxium Travels, pour refaire les travaux pratiques ou en inventer d'autres.