Bonjour à tous,
Suite à la remarque de @pierre-gilles, beaucoup n’ont pas encore vu à quel point Claude rend le développement simple. Voici comment je fais mes intégrations externes et comment je corrige vos bugs, souvent dans la journée 
Petit détail qui a son importance : à la base, je ne suis pas développeur. Si j’y arrive, vous pouvez y arriver aussi 
Ce dont je n’ai pas besoin
Tout ce qu’un développeur utilise d’habitude, je ne m’en sers pas :
- Pas de dev en local
- Pas d’IDE
- Pas de Node ni de Docker à installer sur mon poste
- Pas de commit à la main
C’est justement ce que @pierre-gilles soulignait : beaucoup de développeurs travaillent encore comme ça, alors que ce n’est plus obligatoire.
Ce que je fais à la place
- Je décris le besoin en français, avec des mots simples
- Claude Code web fait tout le reste sur le dépôt GitHub : le code, la pull request, la fusion et la release
- Il me prépare aussi la réponse à poster sur le forum
- Moi, je suis les retours et je teste quand j’ai l’appareil
Ça marche aussi depuis le téléphone, et je peux lancer plusieurs corrections en même temps.
Les bases communes à mes 24 dépôts
- Vérification du manifest à chaque pull request, avec les mêmes contrôles que le store
- Tests automatiques sur Node 22 et 24, lint et format
- Construction de l’image Docker
- Dependabot pour les mises à jour
- Une Release GitHub par version, avec son changelog
- Doc en français et en anglais
Résultat : une erreur est repérée avant d’arriver dans le store.
Comment je démarre une intégration
En attendant le prochain SDK, je donne ce message à Claude Code web, sur un dépôt GitHub vide :
Dans ce repo, sur la branche main, je veux que tu crées une intégration externe "Dyson".
Pars du template d'intégration officiel : https://github.com/GladysAssistant/integration-template-js
N'oublie pas SECURITY.md, CHANGELOG.md et CLAUDE.md
N'oublie pas le tag cloud et/ou local
Mets en place les mêmes workflows que https://github.com/prohand/gladys-devmel
N'oublie pas les widgets, les déclencheurs et les actions de scène
Pourquoi chaque ligne :
- Le template officiel : la structure attendue par Gladys est respectée dès le départ
- SECURITY.md : explique comment signaler une faille
- CHANGELOG.md : garde la trace de chaque version
- CLAUDE.md : les règles du projet pour Claude, relues à chaque nouvelle session
- Tag cloud / local : indique dans le store si l’intégration a besoin d’Internet
- Les workflows de gladys-devmel : tests, contrôles du store, image Docker et releases, déjà prêts
- Widgets, déclencheurs, scènes : sinon Claude se limite souvent aux appareils
Il suffit de remplacer « Dyson » par votre intégration.
Un bug, de A à Z (exemple réel avec Dyson)
1. Vous postez un retour
@mutmut a testé l’intégration Dyson et posté un retour détaillé, avec captures :
2. Je donne le message à Claude Code web
Je colle le lien du message du forum, sur le bon dépôt, et je lui demande de tout faire : la correction, la pull request, la fusion et la release.
Claude lit le retour, cherche la cause dans le code, corrige, ajoute les tests, met à jour la doc et le changelog.
3. Claude ouvre une pull request
Chaque retour du forum devient une pull request. Le titre dit à quel message elle répond.
Dans la pull request, Claude explique ce qui est corrigé, ce qui change et ce qui est ajouté. Il indique aussi ce qui n’a pas pu être testé sur un vrai appareil.
On voit par exemple qu’il a trouvé pourquoi les valeurs PM étaient différentes de Matter : l’intégration lisait la mauvaise série de mesures du Dyson.
4. Les contrôles automatiques passent
Tests, lint, contrôles du store, image Docker : tout est vérifié sur la pull request, puis après la fusion.
Ce sont ces contrôles qui me permettent de laisser Claude aller jusqu’au bout tout seul.
5. Claude fusionne et publie la version
Il fusionne la pull request et lance la release : la Release GitHub, son changelog et l’image Docker sont publiés. La nouvelle version arrive dans le store.
6. Claude prépare la réponse du forum
Je lui demande une réponse pour le forum, et je n’ai plus qu’à la coller. Elle dit ce qui est corrigé, pourquoi, et quoi faire après la mise à jour.
Toutes mes réponses sur le sujet Dyson ont été faites comme ça.
Le résultat sur Dyson
- 1.0.0 le 10 octobre au soir, 1.4.0 le 11 au soir
- 5 pull requests, une par retour de @mutmut
- Corrigé en route : bouton « Mettre à jour » absent, valeurs PM fausses, IP locale ignorée, widget en retard, noms en anglais…
- Et je n’ai pas de Dyson chez moi
Les limites
- Claude peut se tromper : d’où les contrôles automatiques… et vos tests
- Sans l’appareil, je me base sur ce qu’il envoie : vos retours valent de l’or
- Certains soucis viennent du cœur de Gladys. Dans ce cas, je propose un correctif à Gladys (ex. : PR #3188 pour les couleurs des tuiles)
Pour vous lancer (développeur ou pas)
- Créez un dépôt GitHub vide, ouvrez Claude Code web et reliez votre compte GitHub
- Donnez-lui le message de départ ci-dessus, avec le nom de votre intégration
- Commencez petit : une intégration simple, puis un bug, une traduction, un test
- Mettez en place les contrôles automatiques avant de laisser Claude fusionner tout seul : c’est votre filet de sécurité
- Au début, relisez les pull requests pour comprendre ce que fait Claude
Comment m’aider (testeurs)
- Un sujet par intégration sur le forum, ou une issue GitHub
- Indiquez : modèle, version de l’intégration, local ou cloud
- Ajoutez des captures et les logs, sans e-mail, IP ni numéro de série
Plus votre retour est précis, plus la correction est rapide. Merci à tous les testeurs, et à @mutmut en particulier 
(genre, 
