Bonjour tout le monde,
Après différents tests de LLM, je publie un portage du SDK (v0.11.0) pour la création d’une intégration externe en langage Go.
Le lien vers le projet se trouve ici : experimental-gladys-assistant-integration-sdk-go.
Pour valider mon SDK, j’ai rédigé des tests et créé un exemple à partir du projet de @prohand sur la qualité de l’air, car il est plutôt simple.
Histoire du portage
Je voulais tester les capacités de Cline avec mon abonnement Cline Pass en faisant des essais avec plusieurs LLM, afin de trouver la bonne stratégie de développement.
Premier portage en Python
J’ai commencé par un portage en Python en utilisant Qwen 3.8 Max pour établir le plan du projet et réaliser l’analyse du SDK officiel en JS. Ensuite, j’ai utilisé Deepseek V4 Pro pour le développement.
Le SDK en Python fonctionnait, mais l’image Docker d’exemple (qualité de l’air) — qui est pourtant assez simple — prenait 300 Mo d’espace de stockage. Il faut bien stocker Python et toutes les dépendances du projet. Une telle taille pour un si petit code est selon moi une hérésie, et ce n’est pas viable à long terme quand on utilise des dizaines d’intégrations externes.
Nouveau portage en Go
Je suis donc reparti de zéro avec un langage compilé, stable et très utilisé. Mon choix s’est porté sur Go pour les raisons précitées, mais aussi parce qu’il est bien maîtrisé par les LLM et qu’il est développé par Google (un gage de sérieux). Pour info, Docker est d’ailleurs écrit en Go.
Cette fois-ci, j’ai utilisé uniquement un LLM peu coûteux pour voir si cela suffisait, et mon choix s’est porté sur Deepseek V4 Flash. Je l’ai utilisé aussi bien pour le raisonnement que pour le codage.
Ce modèle s’est avéré suffisant. Il n’est pas nécessaire d’avoir un gros modèle comme Fable ou Kimi K3, car @pierre-gilles a fait un super travail avec son README très complet. Il contient tous les détails techniques pour qu’un LLM, même « simple », puisse réaliser un portage. C’est également le cas pour l’intégration externe grâce à son template très bien documenté.
Au final, j’ai maintenant un SDK et un exemple fonctionnels avec une image Docker de moins de 19 Mo. C’est donc très léger en comparaison des 169 Mo de la version JS de @prohand. Rien d’étonnant à cela : la version JS nécessite Node.js et ses dépendances, alors que dans mon cas, il s’agit d’un simple exécutable dans une image basée sur Alpine OS.
Conclusion
Suite à mes tests, le plus important reste la rédaction d’une bonne définition du projet, aussi bien sur les objectifs principaux que sur les aspects techniques, idéalement avec l’aide d’un modèle comme Qwen 3.8 Max / Fable / Opus. Une fois que le fichier README.md, AGENTS.md ou CLAUDE.md est rédigé et complet, on peut passer à un modèle plus léger pour le codage. Dans mon cas, Deepseek V4 Flash a suffi, mais la version Pro reste préférable si le code généré comporte trop d’erreurs ou s’avère trop complexe.
Et maintenant ?
Je ne vais pas maintenir ce projet : il s’agissait d’une expérimentation et je n’aurai pas le temps de m’en occuper à côté de mes autres projets. Vous pouvez évidemment le reprendre si vous le souhaitez, il est complètement libre.
J’espère que ce post vous intéressera et vous aidera dans vos futurs développements !