Loop engineering et Ralph loops
Le loop engineering consiste à encapsuler un agent IA dans un processus récurrent, similaire à un cron job. Au lieu de lancer un prompt ponctuel, le système récupère chaque matin les nouvelles issues, les transmet à l’agent, valide le résultat et escalade les cas bloqués. Cette automatisation réduit l’intervention humaine mais chaque itération consomme des tokens, du contexte et du temps de calcul. Le Ralph loop représente une implémentation brute : l’agent reçoit une tâche détaillée et répète le cycle plan‑act‑check jusqu’à achèvement. Le coût en tokens augmente linéairement avec le nombre de cycles, ce qui rend le modèle plus cher et potentiellement plus lent. La structuration du loop – ajout de primitives comme la validation, le routage et les points de contrôle – vise à limiter les appels inutiles et à améliorer la prévisibilité des ressources.
Squads, fleets et orchestration multi‑agents
Un squad regroupe plusieurs agents aux rôles distincts (planification, validation, implémentation, test, revue). Cette spécialisation reflète une équipe humaine et permet de déléguer chaque sous‑tâche à l’agent le plus adapté. Un fleet déploie plusieurs instances d’un même squad en parallèle, augmentant le débit de traitement. La parallélisation réduit la latence globale mais nécessite une orchestration fine pour éviter les conflits d’accès aux ressources partagées (par exemple, le même dépôt Git). Le modèle de squad‑fleet impose une architecture de type micro‑services où chaque agent expose une API interne, facilitant le monitoring et la mise à l’échelle indépendante.
Harnesses et amélioration continue (hill climbing)
Le harness désigne l’ensemble des outils, permissions, mémoire et logique d’orchestration qui encadrent le modèle. GitHub Copilot illustre ce concept : il relie le modèle à l’IDE, au dépôt et aux pipelines CI/CD, tout en appliquant des filtres de sécurité. La conception d’un harness implique la gestion du contexte (taille du prompt), le stockage persistant des états et la définition de politiques d’accès. Le hill climbing décrit le processus d’optimisation itérative du système à l’aide d’évaluations (evals). Par exemple, on mesure la pertinence des revues de pull‑request, on ajuste les paramètres du harness (prompt template, seuils de validation) et on répète le cycle jusqu’à une amélioration mesurable. Cette boucle de rétroaction repose sur des métriques objectives (taux de bugs détectés, temps de résolution) et expose le risque de sur‑optimisation sur un jeu de données limité.
Modèles fermés, poids ouverts et modèles open source
Les modèles fermés sont accessibles via une API ; les développeurs ne voient ni les poids ni les données d’entraînement, ce qui limite la vérifiabilité et la personnalisation. Les modèles à poids ouverts offrent les fichiers de poids téléchargeables, permettant l’exécution locale ou sur une infrastructure privée, mais la provenance des données d’entraînement reste souvent opaque. Les modèles open source publient le code, les poids, les jeux de données et le protocole d’entraînement, offrant la possibilité d’audit complet, de conformité réglementaire et de modification du comportement du modèle. Le choix entre ces catégories influe sur la sécurité (exposition des clés API vs contrôle local), la conformité (RGPD, licences) et les coûts d’infrastructure (cloud vs on‑premise).
