Créer votre propre module avec Claude

Un module est une petite application faite pour votre organisation — un registre de prêt de matériel, un journal des visiteurs, une liste de prix — que votre équipe ouvre depuis la barre de gauche de PAFworks. Claude Code l’écrit, la teste et la déploie. Rien de ce qu’elle demande ne fonctionne tant qu’un administrateur ne l’a pas approuvé.

Comment ça marche

Un module est une petite application web (Python et Flask) écrite pour votre espace par ses administrateurs — en pratique, par Claude Code en leur nom. PAFworks exécute chaque module à l’écart de tout le reste, dans son propre environnement isolé, et l’affiche dans la barre de gauche à une adresse telle que https://cloud.example.com/mods/loans/.

Les modules déjà écrits par d’autres s’installent aussi en un clic : voir Installer des modules depuis le Store.

Tout ce qu’un module utilise est déclaré dans son fichier module.json. Claude Code le déploie par un connecteur à part, le connecteur de modules ; un administrateur approuve ensuite, sur la page du module, ce qu’il peut faire.

Étape 1 — Allumer les modules

1. Cliquez sur Admin dans la barre de gauche, puis sur Modules dans la liste (avec l’étiquette Expérimental).

2. Cliquez sur Allumer les modules. L’interrupteur indique Activés.

   

Les modules s’allument pour tout votre espace. Éteindre les modules les retire plus tard tous de la barre de gauche : leurs pages ne répondent plus et leurs tâches planifiées s’arrêtent, mais leurs données sont conservées.

La page Modules comporte alors trois parties : l’interrupteur ; Modules de cet espace, une carte par module avec son adresse, sa version et des étiquettes telles que En attente de validation, Inactif ou Le dernier déploiement a échoué — cliquez sur une carte pour ouvrir la page du module ; et Brancher Claude Code, avec vos jetons de développeur. Modules supprimés apparaît en dessous s’il y en a.

Étape 2 — Brancher Claude Code

Claude Code se connecte au connecteur de modules avec un jeton de développeur : une clé à part, qui ne fonctionne que pour un administrateur, que pour les modules, et jamais comme mot de passe pour la messagerie ou les fichiers.

1. Dans Brancher Claude Code, sur la même page, saisissez un Nom (Claude Code si vous le laissez vide). Pour limiter le jeton dans le temps, saisissez un nombre de jours dans Expire après (jours) ; vide, il n’expire jamais. Cliquez sur Créer un jeton.

2. Copiez le jeton tout de suite : il n’est affiché qu’une fois. En dessous, la page donne la commande à lancer dans le terminal où travaille Claude Code, jeton compris.

   

3. Lancez cette commande dans un terminal, depuis le dossier où vous construirez vos modules. Elle ressemble à ceci :

   claude mcp add --transport http cloud-example-com-modules https://cloud.example.com/mcp-modules --header "Authorization: Bearer dcmod_…"

Étape 3 — Demander un module à Claude

Lancez Claude Code dans un dossier vide et décrivez ce qu’il vous faut avec vos propres mots : ce que le module affiche, ce qu’on y fait, et ce qui doit se passer tout seul. Par exemple :

Claude en fait un module qui déclare ce dont il a besoin — pour celui-ci, l’envoi de notifications dans PAFworks et une tâche planifiée. Ses pages ressemblent au reste de PAFworks et reprennent les couleurs de votre organisation.

Étape 4 — Claude construit, teste et déploie

Vous pouvez suivre chaque étape dans Claude Code. Les outils du connecteur de modules sont indiqués entre parenthèses.

1. Il lit le guide des modules (module_guide) : les règles d’un module, la boîte à outils avec laquelle il s’écrit, les règles de design, le catalogue d’actions, des recettes et le fonctionnement du déploiement.

2. Il télécharge le kit (get_module_kit) : la boîte à outils, l’outil de test local dcmod-dev, un squelette fonctionnel pour démarrer et un fichier de règles CLAUDE.md. L’outil répond par une commande, valable 10 minutes, que Claude lance dans votre dossier.

3. Il écrit le module : module.json, l’application, ses gabarits de page et les fichiers qui créent sa base de données.

4. Il le teste sur votre ordinateur avec dcmod-dev : il vérifie, comme le fait un déploiement, que les changements de base de données s’appliquent et que le module démarre, puis il ouvre ses pages dans une copie locale de PAFworks, captures d’écran comprises. Les e-mails ne sortent jamais de dcmod-dev.

5. Il le déploie (deploy_module) : une autre commande, lancée dans le dossier du module, empaquette le dossier, vérifie son empreinte et l’envoie à votre espace.

6. Il lit le rapport (module_status) : déployé, échec — avec le fichier et la ligne en cause — ou en attente de validation. Un déploiement en échec ne remplace jamais la version en service : Claude corrige le code et déploie de nouveau. Un premier déploiement vous attend toujours : Claude vous le dit.

Pour trouver un problème, Claude lit les journaux du module (module_logs) et ouvre lui-même ses pages (call_module) : en votre nom, comme invité d’un workspace, ou comme visiteur non connecté. rollback_module revient à la version précédente, après avoir indiqué quelles données seraient perdues.

Étape 5 — Approuver le premier déploiement

1. Ouvrez Admin › Modules. Sous Modules de cet espace, le nouveau module indique En attente de validation et pas encore en service. Cliquez dessus.

   

2. Lisez le haut de la page : la version en attente, quand et par qui elle a été envoyée, et Ce que ce module utilise, en termes simples — ici, Envoie des notifications et la tâche planifiée overdue. Ce que la version en service n’utilisait pas déjà porte la mention nouveau : lors d’un premier déploiement, tout.

   

3. Sous Droits, cochez ce que vous acceptez. Seul ce que le module déclare est proposé. Une tâche planifiée s’exécute au nom de l’administrateur qui l’active, avec les droits de cet administrateur. Cliquez sur Approuver et déployer 1.0.0.

   

4. Le déploiement démarre. Son rapport apparaît sous Déploiements : chaque étape cochée, des vérifications de l’archive au passage à la nouvelle version. Le module est maintenant en service.

   

Une action que vous laissez décochée est refusée quand le module l’appelle. Par la suite, Enregistrer les autorisations change ce qu’un module en service peut faire, sans rien déployer.

Ce que voient vos utilisateurs

Le module apparaît dans la barre de gauche, avec son icône et son libellé, pour les personnes autorisées à l’utiliser. Il s’ouvre à l’intérieur de PAFworks, aux couleurs de votre organisation.

À propos de ce module, en haut à droite, liste ce qu’il utilise et indique si chaque élément a été approuvé.

• Il agit au nom de la personne qui l’utilise. Tout ce qu’un module fait dans votre espace — lire un contact, créer une tâche — il le fait avec exactement les droits de la personne devant lui. Les changements qu’il apporte aux fichiers figurent dans leur activité avec la mention « via le module ».
• L’intelligence artificielle est annoncée. Quand un module peut envoyer à un modèle de langage ce que saisissent les utilisateurs, un bandeau l’indique au-dessus de lui.
• Un module qui ne peut pas répondre affiche un court message dans sa page ; le reste de PAFworks n’est pas touché.

Choisir qui l’utilise

La section Général de la page du module décide où il se trouve et qui le voit. Cliquez sur Enregistrer après un changement.

Ce qu’un module peut demander

Un module déclare dans module.json tout ce qu’il utilise. Ce qu’il ne déclare pas ne fonctionne pas et n’est pas proposé à l’approbation ; ce qu’il déclare ne fonctionne pas tant que vous ne l’accordez pas sous Droits.

Mettre à jour un module

Demandez le changement à Claude dans le même dossier. Il déploie une nouvelle version de la même manière.

• Rien de nouveau demandé : la nouvelle version entre en service immédiatement, sans votre approbation. Une version qui demande moins n’en a pas besoin non plus.
• Quelque chose de nouveau demandé — une action, une passerelle, une tâche planifiée, une page publique, une page de workspace ou un secret : la version attend un administrateur, et la version en service continue de tourner jusqu’à votre approbation. La page signale ce qui est nouveau.
• Une seule version en attente à la fois : un déploiement ultérieur remplace celle qui attend.
• Les données suivent. Les changements de base de données de la nouvelle version s’exécutent d’abord sur une copie : un déploiement qui échoue à n’importe quelle étape laisse la version en service et ses données telles quelles.

Surveiller, revenir en arrière, restaurer

Plus bas sur la page du module :

• Suivi : son état, la taille de sa base de données, sa consommation de mémoire et de processeur, ce que son IA a coûté ce mois-ci, et Dernières lignes du journal. stopped est normal pour un module que personne n’a utilisé depuis un moment : il redémarre à la visite suivante. failed suit trois plantages en dix minutes, jusqu’au prochain déploiement ou à un changement de ses réglages.
• Déploiements : chaque version envoyée, avec son rapport — étapes, erreurs avec fichier et ligne, avertissements.
• Revenir à la version précédente, affiché dès qu’il y en a une, revient à la version précédente et à sa base de données : tout changement fait depuis le déploiement de la version actuelle est perdu. Claude peut faire de même avec rollback_module, après vous avoir indiqué ce qui serait perdu.
• Copies des données : PAFworks copie la base de données du module toutes les heures quand elle a changé, et conserve les 24 dernières copies ainsi qu’une par jour pendant 14 jours. Restaurer remet une copie en place ; tout ce qui a été écrit depuis est perdu.
• Effacer les données, sous Réinitialiser les données, démarre la version en service sur une base de données vide. Une copie est prise d’abord, pour pouvoir la restaurer.

Supprimer un module

En bas de la page du module, cliquez sur Supprimer ce module et confirmez. Il quitte immédiatement la barre de gauche. Ses données sont conservées, et vous pouvez le faire revenir avec Restaurer sous Modules supprimés sur la page Modules pendant 30 jours ; ensuite, il est effacé pour de bon.

Bon à savoir

• Expérimental, et une option du serveur. Sans hôte de modules, l’administration n’a pas d’entrée Modules, et ni les pages ni le connecteur n’existent. Demandez à votre fournisseur.
• Plafonds. Par défaut, un espace contient jusqu’à 20 modules ; un module dispose de 256 Mo de mémoire sauf s’il en demande plus (512 Mo au maximum) et d’une base de données de 512 Mo au plus ; une version envoyée pèse au maximum 20 Mio. Votre fournisseur fixe ces limites.
• Un environnement isolé rien que pour lui. Un module ne peut ni ouvrir de connexion réseau, ni lancer de programme, ni lire autre chose que ses propres fichiers et données. Internet, la messagerie et l’IA ne passent que par les passerelles que vous ouvrez.
• Gardez le dossier du module. Son code source reste sur votre ordinateur : PAFworks conserve les versions qu’il exécute, mais l’interface web ne propose pas de les télécharger. Un dépôt Git lui convient bien.
• Les jetons de développeur ne sont stockés que sous forme d’empreintes. Un jeton cesse de fonctionner quand il expire ou est révoqué, quand son propriétaire n’est plus un administrateur actif, et tant que les modules sont éteints.
• Des commandes à courte durée de vie. Les commandes données à Claude pour télécharger le kit et envoyer une version fonctionnent 10 minutes ; ensuite, il en redemande au connecteur.
• Les tâches planifiées s’exécutent 5 minutes au maximum, jamais deux fois en même temps, et sont ignorées si l’administrateur qui les a activées ne l’est plus.