Cognition intègre l'agent Devin à la plateforme MongoDB : des migrations 4–5 fois plus rapides

Cognition et MongoDB ont branché l'agent Devin à l'Application Modernization Platform (AMP), l'outil de MongoDB pour migrer des applications legacy vers Atlas. Le produit s'appelle Devin for MongoDB Modernizations et il est déjà disponible pour les clients des deux entreprises. Dans les premiers tests menés conjointement, des tâches qui prenaient cinq à six heures demandent désormais un peu plus d'une heure, soit un gain d'un facteur 4–5 environ. La promesse des éditeurs est ambitieuse : migrer des décennies d'applications accumulées en quelques mois, et non en plusieurs années.

Où les migrations coincent vraiment

La formulation de l'annonce est révélatrice : les migrations vers MongoDB butent rarement sur la base elle-même. Le problème tient à la « tuyauterie » autour de l'ancien code : des milliers de requêtes, de procédures stockées et de couches d'accès aux données qui, pendant des années, se sont chargées de logique métier. Un script n'y suffit pas. Il faut comprendre pourquoi telle requête est écrite de telle façon, et ce qui casserait si on la remplaçait.

C'est précisément le terrain que Cognition vise avec Devin. L'agent travaille sur l'ensemble de la base de code : il planifie les modifications, réécrit la logique métier et la data access layer, en traitant chaque cas séparément. C'est justement ce type de travail qui absorbe la capacité des équipes d'ingénierie, comme le dit explicitement Scott Wu, CEO de Cognition : même les équipes les plus ambitieuses consacrent une part importante de leurs ressources à la maintenance des anciens systèmes.

Comment Devin et AMP se partagent le travail

L'architecture repose sur une séparation des responsabilités entre un composant non déterministe et un composant déterministe. Pour la migration des données, le risque d'hallucination est inacceptable : le transfert et la vérification de chaque enregistrement dans MongoDB sont donc confiés à l'outillage éprouvé d'AMP. Le code, là où il faut de la souplesse, est laissé à l'agent. Devin se connecte directement aux outils d'AMP et orchestre le processus de bout en bout. Le client voit ainsi une migration cohérente, et non un assemblage de scripts et de transferts manuels entre équipes.

Les principaux paramètres de l'annonce :

• Rôle de Devin : planification, réécriture de la logique métier et des couches d'accès aux données.
• Rôle d'AMP : transfert déterministe et validation des enregistrements dans MongoDB Atlas.
• Reste du côté des humains : conception du modèle de données cible et séquence du cutover.
• Résultat des premiers tests : de 5–6 heures à un peu plus d'une heure par tâche.
• Disponibilité : immédiate pour les clients de MongoDB et de Cognition ; la documentation pour connecter Devin à MongoDB est publiée.

La frontière entre ce qui est automatisé et ce qui reste du ressort de l'humain est raisonnablement placée. Le modèle de données d'une base documentaire est une décision d'architecture dont les conséquences durent des années, et l'ordre de bascule, qui dépend des risques métier, ne doit pas être délégué à un agent.

Ce que l'on sait des résultats, et ce que l'on ignore

La seule métrique publiée est celle des « premiers tests menés conjointement ». La méthodologie n'est pas dévoilée : on ne sait pas ce qui était compté comme une tâche, sur quelles bases de code les mesures ont été faites, ni comment le temps de relecture par un humain a été pris en compte. Le document a été publié sur le blog de Windsurf, lié à Cognition ; il s'agit donc d'une auto-description de l'éditeur, et non d'une évaluation indépendante.

La voix la plus concrète de l'annonce est celle de Bilt. Son directeur technique, Kosta Kraut, explique que l'entreprise écrit l'essentiel de son logiciel avec Devin et déploie en production tous les jours. La recherche par quartier sur bilt.com, première chose que voit l'utilisateur, tourne sur MongoDB ; avec Devin, Bilt migre les autres charges de recherche vers la même base, dans des délais impossibles à tenir à la main. Il s'agit d'un seul client et d'un seul scénario, mais cela montre comment l'association s'applique dans un produit réel.

MongoDB a sa propre motivation. Son CEO, Dev Ittycheria, la formule ainsi : l'enjeu est de moderniser simultanément la plus grande part possible du parc applicatif d'une entreprise, et non application par application. En parallèle, la société défend l'idée d'une data foundation moderne pour les applications d'IA et les agents qui travaillent sur des données opérationnelles en temps réel. Ici, la migration sert d'entonnoir vers Atlas.

Comment l'appliquer en pratique

Si vous avez des applications legacy sur des bases relationnelles et une migration vers MongoDB qui traîne dans le backlog, il est judicieux de demander un pilote sur un service non critique. Mesurez non seulement la vitesse de génération du code, mais aussi le temps total jusqu'à la production, relecture et validation des données comprises.

Fixez à l'avance le modèle de données cible et le plan de cutover : ces décisions restent de votre côté et déterminent dans quelle mesure l'agent accélérera le travail. Vérifiez aussi comment AMP valide les enregistrements : la confiance dans le résultat dépend davantage de l'exhaustivité de cette vérification que de n'importe quel chiffre de l'annonce.