Chapitre 24 / 39

Bibliothèque de skills

Un skill est un workflow IA nommé — un court fichier markdown qui décrit ce que l’IA doit faire quand il est appelé dans une situation précise. brief <client> est un skill. visit-debrief est un skill. Le rapport mensuel est un skill. Chacun représente quelques paragraphes d’instructions et une liste des outils que l’IA est autorisée à appeler.

Le livrable de Thomas ici est l’infrastructure pour créer, partager et exécuter des skills à travers l’équipe — pas un catalogue figé de skills. L’équipe fait grandir le catalogue au fil du temps, face à ses workflows réels, en utilisant les outils de ce chapitre. Certains skills seront rédigés pendant la mission comme exemples de référence ; le reste est à construire par Rani, Paul, Jack et toute personne qui rejoindra l’équipe plus tard.

Statut : Bloqué — l’infrastructure s’active une fois le Framework Desktop en production et les données Sodiwin en flux vers l’entrepôt.

À quoi ressemble un skill

Un skill est un fichier markdown avec un bloc frontmatter — rien de plus. Le frontmatter nomme le palier qu’il utilise (rapide, qualité, ensemble), les outils qu’il est autorisé à appeler, et les personnes qui doivent approuver le résultat avant qu’il soit envoyé. Le corps est de la prose ordinaire : la séquence que l’IA doit exécuter à chaque fois que le skill est invoqué.

Trois propriétés découlent de ce format :

Versionné. Les skills vivent dans un dépôt git. Chaque modification a un auteur, un horodatage et une raison. Un skill qui dérive, c’est un diff à lire.
Portable. Le même fichier s’exécute face aux modèles locaux, aux modèles cloud, ou via Claude.ai. Le palier est le contrat ; le modèle qui le sous-tend peut être remplacé.
Lisible. Un skill est de la prose, pas du code. Rani, Paul ou Jack peuvent lire n’importe quel skill et savoir ce qu’il fait — et en modifier un sans passer par Thomas.

Comment l’équipe invoque un skill

Trois chemins, les mêmes fichiers en arrière-plan :

Terminal. Une courte commande depuis le laptop de l’utilisateur — brief acme-bistro, visit-debrief, followup acme-bistro. Utile au milieu d’un workflow, avec des arguments prévisibles.
Claude.ai. L’équipe pose la question en langage naturel et le skill correspondant s’exécute via l’outillage MCP partagé. Utile pour les questions exploratoires qui seraient difficiles à formuler comme commande.
Programmé. Le système exécute le skill sur un minuteur — briefs du matin à 07:00, alertes churn overnight, rapport mensuel le premier du mois.

Un skill est rédigé une fois et rendu disponible sur les trois surfaces. L’équipe n’a pas à choisir quel mode construire.

Comment les skills sont partagés

Les skills résident dans un dépôt git que toute l’équipe peut lire et alimenter. Un skill proposé par Rani arrive sous forme de pull request ; Paul ou Jack peut commenter, approuver et fusionner. Le skill fusionné devient disponible pour tous à la prochaine synchronisation.

Le même dépôt contient le catalogue d’outils (ce que l’IA peut appeler — voir le chapitre Ce à quoi l’IA peut accéder) et les règles d’escalade (quand un skill est autorisé à utiliser le palier cloud). Tout ce que l’IA fait chez Sodimo est accessible à la relecture à un dépôt de distance.

Ce qui est rédigé pendant la mission

Thomas rédige un petit nombre de skills pendant la mission comme exemples de référence, pour que l’équipe dispose d’un modèle à copier. L’ensemble est indicatif et peut évoluer selon ce que l’équipe demande en semaine 3 ou 4 :

Un brief d’appel (Rani, vente) — le modèle pour tout skill qui consolide l’état récent d’un client en une page.
Un rédacteur de lettres de relance (Paul, finance) — le modèle pour tout skill qui rédige un texte soumis à approbation humaine.
Un brief du matin (par rôle) — le modèle pour tout skill planifié qui compose un email quotidien.
Un debrief de visite (Rani, terrain) — le modèle pour tout skill qui transforme des notes brutes en fiche structurée.

L’intérêt de cette liste n’est pas la liste. Ce sont les quatre formes — « consolider l’état en une page », « rédiger pour approbation humaine », « composer un email planifié », « transformer des notes brutes en fiche ». La plupart de ce que l’équipe voudra construire en année un est une variation sur l’une de ces formes.

Publication de dashboards

Une forme de skill mérite d’être mise en avant parce qu’elle libère l’autonomie de reporting de l’équipe.

Un membre de l’équipe ouvre Claude Code face à des données en direct, demande un graphique ou une vue, examine le résultat, et le publie sur Cloudflare Pages depuis la même session. Le résultat est un dashboard interne en direct à sa propre URL, lisible sur téléphone ou desktop, accessible uniquement à l’équipe. L’idée de Rani d’une vue « Top of Mind » par commercial est le premier exemple.

C’est la forme qui permet à l’équipe de maîtriser son propre reporting sans attendre que quelqu’un le construise pour elle. Chaque question récurrente qui mérite sa propre page devient une session de création de deux minutes, pas un ticket.

Heuristiques que Thomas enseigne à l’équipe, sans les imposer dans l’interface

Deux principes appartiennent à la tête de l’équipe, pas à une contrainte d’interface :

Commencer local, escalader quand nécessaire. La plupart des requêtes devraient être traitées par le palier rapide sur le Framework Desktop. Les paliers qualité et ensemble, et l’escalade vers le cloud, sont réservés au petit ensemble de requêtes où le temps et le coût supplémentaires sont justifiés. Un skill qui envoie systématiquement un brief du matin à Claude est un skill à réécrire — pas un skill à bloquer.

Améliorer le modèle derrière un palier, pas le palier dans chaque skill. Quand un meilleur modèle local arrive, il remplace l’ancien au sein du palier. Tous les skills étiquetés « rapide » s’améliorent d’un coup. L’équipe ne réécrit pas ses skills pour suivre les modèles.

Ces deux principes sont inscrits dans la façon dont l’équipe utilise la stack — le manuel est l’endroit où ils atterrissent en premier ; l’outillage les suppose plutôt qu’il ne les impose.