Je me suis pris le mur de la complexité à la 9e implémentation de Busy. J’ai donc fait quelques recherches. Deux candidats principaux pour des langages de programmation à faible charge cognitive. Lua avait le meilleur score. Léger, tant au niveau du projet que des modules. Je connais Lua, ça ne me dérangerait pas de bosser avec... pensais-je, naïvement.
Le vrai problème avec Lua, c’est que c’est un projet obsolète et abandonné. Il n’y a plus de versions actuelles, et c’est conçu pour être intégré, pas pour être utilisé directement dans une app. C’est problématique pour ce que je veux faire.
Dart a le score de complexité cognitive le plus bas après Lua. Plus petit que Go, marginalement plus léger par module, nettement plus simple par fichier, à peu près au niveau de Lua. C’est donc ça que j’ai choisi.
L’autre grosse différence dans ce build, c’est l’approche. Bon, retour aux principes de base... a-t-on vraiment besoin d’un chatbot en temps réel ? Probablement pas. Ce dont on a besoin, c’est de quelque chose qui s’articule autour du code.
J’ai donc passé le week-end à écrire ce système absolument magnifique. C’est un système à deux niveaux. Écrit en Dart pour l’app client, et en PHP qui tourne sur un hébergeur web. Mais... j’ai dû créer un tunnel pour le callback et initier une transaction FTP pour le tunnel, pour que l’app PHP sache qui appeler.
Faites n’importe quoi sur GitHub dans un dépôt abonné, et le système le capte ! Et c’est comme ça que l’implémentation 10 va fonctionner. Du moins, au niveau bas. Pour ce genre de trucs, c’est important de penser à la plomberie d’abord, avant de réfléchir aux fonctionnalités de l’agent avec l’IA.
La plomberie est superbe... mais le tunnel n’était pas conçu pour ça. Il expire vite et gère mal les reconnexions. La moitié du temps, le système se contentait d’initier une transaction, de tomber en timeout, et de répéter le processus jusqu’à atteindre le backoff exponentiel max, avant de s’éteindre.
J’ai donc regardé les solutions de tunnel payantes pour tout gérer localement et j’ai évalué mes options avec soin. Et j’ai réalisé que je pouvais simplement acheter un VPS chez l’hébergeur avec lequel je bosse déjà, ce qui réglerait le problème de tunnel en assignant une IP dédiée à l’app. Et pour 5 $ par mois, j’ai tous les gadgets serveur dont une fille puisse rêver. Publication via un dépôt git sécurisé, accès sudo si besoin, et...
Bon, maintenant, les hypothèses clés sur lesquelles je me suis basée pour le design n’ont plus aucun sens logique, et je dois tout refondre. Enfin, pas tout. C’est ça la joie de l’architecture modulaire. Donc aujourd’hui, je suis en train de bricoler tout ça et de déplacer des composants.
Je vais consolider la fonctionnalité de webhook dans l’app Dart, avec tous mes endpoints sécurisés et la gestion de la base de données, et avec un peu de chance, me débarrasser de tout ce code PHP cognitivement dense (mais fonctionnel). Je garde la base de données au même endroit et je liste le VPS en blanc pour bien séparer les responsabilités. Et une fois fini, je n’aurai plus qu’à faire deux ou trois modifs rapides dans la configuration de l’app GitHub, et on est dans le vrai.
Étape suivante : ajouter l’IA elle-même !