Devin

Comment ça marche

Devin travaille dans un environnement cloud qui lui est propre : un navigateur, un terminal, un éditeur de code. On lui confie une tâche, par un message ou en lui assignant un ticket. Il explore le dépôt, planifie, écrit le code, lance les tests, cherche dans la documentation en ligne quand il bloque, et ouvre une pull request avec un compte rendu. On peut le suivre en direct et intervenir. Il s’intègre aux outils d’équipe (dépôt, messagerie, suivi de tickets).

Son histoire est instructive. L’annonce de 2024 promettait un ingénieur autonome ; les premiers retours indépendants ont montré des résultats inégaux ; l’outil a progressé, baissé de prix et trouvé sa place : traiter les tâches cadrées d’une équipe qui relit. Pour une entreprise, la leçon vaut pour tous les agents autonomes : évaluer sur ses propres tâches, avec des critères, et déduire le périmètre de ce qui marche. La qualité des tests existants et de la description de la tâche fait l’essentiel du résultat.

Un exemple concret

1. Le protocole : 40 tickets réels de trois projets clients, classés par difficulté et par qualité de la base de code (avec ou sans tests). Un mois d’essai. Chaque pull request relue et notée par un développeur senior.
2. Résultats sur les projets avec tests : 24 tickets sur 28 fusionnés après relecture, dont 15 sans modification. Les corrections de bugs et les petites fonctionnalités, très bien ; les refontes, moins.
3. Résultats sur le projet sans tests : 5 tickets sur 12 fusionnés, 4 pull requests qui cassaient quelque chose sans le savoir. L’agent n’avait aucun moyen de vérifier son travail.
4. La conclusion : l’outil est adopté pour les deux projets testés, et le troisième projet reçoit d’abord une campagne d’écriture de tests, en partie par l’agent lui-même.
5. Le chiffre retenu : le coût de l’abonnement représentait environ 15 % du temps de développeur économisé sur les projets testés.

L’évaluation a pris un mois et a répondu à la question utile : sur quoi ça marche chez nous. Pas « est-ce un ingénieur ».

Ce que ça change pour une équipe

• Les tâches cadrées se délèguent. Bugs décrits, petites fonctionnalités, mises à jour : traités en arrière-plan, relus.
• Les tests deviennent une priorité. Sans eux, l’agent travaille à l’aveugle. Avec eux, il est fiable.
• L’évaluation a une méthode. Des tickets réels, des critères, un mois : ça vaut pour tous les agents.
• Le discours se calme. Ni ingénieur remplacé ni gadget : un outil avec un périmètre mesuré.

Les limites et les erreurs fréquentes

• Croire l’annonce. Un agent autonome ne remplace pas une équipe. Il la décharge de tâches définies, sous relecture.
• Le lancer sur une base sans tests. Les pull requests qui cassent sans le savoir sont le résultat garanti. Les tests d’abord.
• Des tickets vagues. « Améliorer l’expérience utilisateur » ne donne rien. Une tâche, un résultat attendu, des critères.
• Fusionner sans relire. La relecture humaine reste le garde-fou, quel que soit le taux de réussite constaté.