Jongler avec les outils IA, ça marche… jusqu'à ce que ça ne marche plus

Ce n’est pas une critique. Cette stack est une façon tout à fait raisonnable de démarrer. Un éditeur axé sur l’IA gère l’écriture au quotidien. Un agent de codage en terminal prend en charge les tâches qui nécessitent plus d’autonomie : une fonctionnalité complète, une migration, un bug tenace. Quelques scripts relient les éléments entre eux, déclenchent une exécution et affichent le résultat quelque part. Un outil d’observabilité vérifie ce qui s’est passé après coup.

Chaque élément de cette architecture est un outil réel et performant. Pendant les premiers mois, au sein d’une petite équipe, ça marche. Le point faible ne réside pas dans un outil en particulier. Il réside dans ce que personne n’a construit entre eux.

Ce qui est vraiment bien avec cette stack

Point clé : le stack est rapide à mettre en place car il est entièrement constitué d’éléments qu’une petite équipe connaît déjà, sans nouvelle infrastructure ni nouvelles relations avec des fournisseurs.

Un éditeur axé sur l’IA offre à chaque développeur un cycle de développement plus rapide, des suggestions en ligne, un chat et des refactorisations ; le tout directement là où il écrit déjà son code. Un agent de codage basé sur un terminal va encore plus loin : il confie une tâche bien définie et reçoit en retour une tentative fonctionnelle. Les scripts sont peu coûteux et rapides à écrire — un webhook par-ci, une tâche cron par-là — et ils permettent à une petite équipe d’automatiser les étapes répétitives évidentes sans avoir à attendre personne d’autre. Un outil d’observabilité, pointé vers les bons logs, te permet de voir qu’une tâche s’est exécutée et, en gros, ce qu’elle a fait.

Où ça coince, et ce n’est pas à cause des outils

Point clé : le compromis apparaît dès que plus d’une ou deux personnes dépendent simultanément de la stack, et ce à trois niveaux précis : le coût, la charge de révision et le partage des connaissances.

• Un coût que personne ne peut expliquer. Chaque outil facture séparément, selon ses propres conditions et sa propre granularité. Un script déclenche l’exécution d’un agent de codage. L’exécution effectue des tentatives répétées ou va plus loin que prévu. Personne ne s’en rend compte avant de recevoir la facture, et même là, celle-ci ne précise pas quel processus, quel dépôt ou quelle tâche a réellement généré ces dépenses. L’outil d’observabilité n’a pas été conçu pour répondre à cette question ; il a été conçu pour surveiller l’infrastructure, pas pour attribuer la consommation de jetons d’un agent à la décision qui l’a provoquée.    
   
• Une charge de révision qui dépasse les capacités des réviseurs. L’éditeur et l’agent de codage permettent tous deux de générer plus de code plus rapidement qu’une seule personne ne pouvait en écrire auparavant. Rien dans cette stack ne change qui révise le code, ni comment. La file d’attente de révision absorbe la différence, mais de manière inégale. Celui qui se trouve libre révise ce qui se présente ensuite, peu importe le niveau de rigueur que cette modification spécifique nécessite réellement.    
   
• Pas de guide commun. Chaque script est écrit par celui ou celle qui l’a créé, pour résoudre le problème qu’il ou elle avait cette semaine-là. Il n’y a pas de définition commune de ce qu’est réellement un processus, de ce qui devrait être interrompu par un humain ou non. Quand cette personne est absente ou change d’équipe, le processus qu’elle a mis en place part avec elle, à moitié documenté au mieux, et n’est dans la tête de personne d’autre.

Ce ne sont pas des bugs dans l’éditeur, l’agent ou l’outil d’observabilité. Chacun a été conçu pour bien faire son boulot. Ce qui manque, c’est la couche entre eux, et créer cette couche n’a jamais fait partie de leurs missions de toute façon.

Il faut le dire franchement : une couche commune ne supprime pas la prise de décision quant à ce qui relève d’un risque faible ou d’un risque élevé. Cette décision doit toujours être prise par quelqu’un. Ce qui change, c’est l’endroit où elle se trouve : dans une définition du processus que tout le monde peut voir et réutiliser, plutôt que dans l’esprit de l’ingénieur qui a écrit le script par hasard.

Ce qu’une couche commune doit réellement faire

Point clé : la solution, ce n’est pas un quatrième outil. C’est une couche conçue dès le départ pour servir de lien entre les outils déjà utilisés.

La solution, ce n’est pas un quatrième outil rajouté aux trois autres. C’est une couche conçue dès le départ pour servir de lien : un processus défini plutôt qu’un script, un contrôle humain qui constitue un véritable point de décision plutôt qu’une file d’attente où tout le monde se jette, et un enregistrement des coûts et des actions attribués à l’exécution qui les a générés, et non reconstitués à partir d’une facture quelques semaines plus tard.

Upsun Dispatch™ est conçu pour être cette couche. Il ne remplace pas l’éditeur dans lequel tes développeurs codent, ni l’agent de codage qui effectue le gros du travail. Il fonctionne indépendamment de celui qui a produit le changement, déclenché par les mêmes événements du dépôt, exécutant le processus que le reste de la stack n’a jamais été conçu pour exécuter, et enregistrant ce qui s’est passé au fur et à mesure.

Consulte la documentation d’Upsun Dispatch pour découvrir comment le processus et la couche de contrôle sont réellement construits.

Foire aux questions (FAQ)

Faut-il remplacer nos outils actuels pour utiliser Upsun Dispatch ?
Non. Upsun Dispatch fonctionne en parallèle de ta stack, il ne la remplace pas. Il exécute ses propres processus de planification, de codage et de révision avec les outils que tu utilises déjà (GitHub, GitLab, Jira) ; tu n'as pas besoin d'abandonner ton éditeur ou ton agent de codage pour l'adopter.

À partir de quand une configuration basée sur des scripts devient-elle vraiment un problème ? En général
, dès que plusieurs personnes en dépendent en même temps. Les scripts personnels d’un développeur suffisent pour ce développeur-là. Les limites apparaissent quand la charge de révision, le coût et la maîtrise du processus doivent s’étendre au-delà d’une seule personne.

Est-ce une critique d’un outil spécifique de cette stack ?
Non. Chaque outil remplit bien la fonction pour laquelle il a été conçu. Aucun d’entre eux n’a été conçu pour servir de couche commune dont une équipe a besoin dès lors que plusieurs personnes s’appuient sur la même configuration, et c’est un problème différent de celui d’un outil qui ne remplirait pas sa fonction.