De l'idée à l'outil

Les cinq temps : idée, concept, réalisation, épreuve, mise en service

Tout ce que décrit ce site a été construit de la même façon. Un irritant du quotidien devient une idée, l’idée devient un concept, le concept se réalise avec Claude, passe l’épreuve des tests, puis est mis en service et entretenu. Sauter un temps coûte toujours plus cher que de le faire.

Les cinq temps

1. Idée : le problème en une phrase

  • Écrire le problème, pas la solution : « chaque absence déclenche une chaîne de mails et des box restent vides ».
  • Vérifier qu’il revient : une fois par semaine au moins, ou trois fois la même consigne.
  • Choisir un premier besoin ; les autres attendront.

Point d’alerte : vouloir tout automatiser d’un coup. Commencez par ce qui fait perdre le plus de temps.

2. Concept : ce que sera l’outil

  • Choisir la forme : un skill (un savoir-faire que Claude applique), un artefact (une page que vous consultez), une routine (une tâche planifiée), un projet (un espace de travail par casquette), ou un outil en ligne (pour des personnes qui n’utilisent pas Claude).
  • Définir les entrées, la sortie et le livrable : ce que l’outil lit, ce qu’il produit, où il le range.
  • Écrire les garde-fous avant la première ligne : ce qu’il ne fera jamais sans votre accord.
  • Lister les questions ouvertes et les trancher avant de construire.

Point d’alerte : une spécification comprise d’une seule personne. Faites-la relire par Claude : « qu’est-ce qui est ambigu ? ».

3. Réalisation : ce qu’on demande à Claude

  • Une première version minimale, puis de petites demandes successives.
  • Chaque livraison numérotée (v1, v2…), l’ancienne archivée.
  • Les données réelles jamais embarquées dans ce qui sera partagé.

Point d’alerte : corriger dix choses dans une seule demande. Une demande, une modification, un test.

4. Épreuve : prouver que ça marche

  • Tester sur un cas réel, puis sur un cas limite (données absentes, nom inconnu, geste inhabituel).
  • Faire vérifier par Claude ce qu’un humain ne relit plus : écarts entre deux sources, noms, identifiants, liens.
  • Ne rien corriger sans accord : l’épreuve produit une liste, pas des modifications.

Point d’alerte : un test qui passe sur votre poste ne prouve rien pour celui de vos collègues.

5. Mise en service : livrer, publier, faire durer

  • Livrer toujours la même chose, au même endroit, sous le même nom.
  • Écrire la procédure de publication pour quelqu’un qui ne l’a jamais faite, avec ce qu’il doit voir à la fin.
  • Annoncer aux utilisateurs par un mail rédigé dans la conversation et envoyé par vous.
  • Compresser la discussion en skill : les difficultés résolues ne doivent pas être réapprises.

Point d’alerte : un outil sans propriétaire ni procédure meurt à la première panne.

Les cinq temps, selon ce que vous construisez

Skill Artefact Routine Projet Outil en ligne
Idée Une consigne donnée trois fois Une question posée chaque jour Une vérification faite chaque jour Des conversations mélangées Des collègues qui n’ont pas Claude
Concept Nom, déclencheurs, étapes, livrable, garde-fous, passages de main Une seule question par page ; données en base, pas dans la page Un plan de marche écrit dans un fichier ; budget Une casquette par projet ; documents de référence ; frontières Spécification, onglets, architecture, droits
Réalisation Demander à Claude de rédiger le skill à partir de la conversation Publier la page, puis la brancher sur une base Créer la tâche qui lit le plan Créer le projet, y déposer consignes et documents Construire version par version
Épreuve Le tester sur trois demandes réelles Vérifier sur téléphone et à plusieurs Relire le journal des premiers passages Vérifier qu’une question va dans le bon projet Triple test, double vérification
Mise en service L’inscrire sur la carte des compétences L’épingler ; archiver les doublons Superviser par voyants ; notifier seulement si action Épingler les conversations utiles Publication en quatre clics, annonce, skill

Voir un cas complet