AWS et GitLab associent leurs IA pour simplifier le développement logiciel

Le développement logiciel est devenu un assemblage complexe de tâches et d’outils : écrire du code, le tester, le faire relire, repérer des vulnérabilités, corriger les défauts, puis le déployer. C’est sur cette chaîne de production que AWS et GitLab veulent intervenir. Leur collaboration associe GitLab Duo, l’assistant d’IA de GitLab, aux capacités d’agents autonomes d’Amazon Q Developer, avec l’ambition de proposer une expérience plus intégrée aux équipes qui conçoivent et maintiennent des applications.

L’annonce, rendue publique début décembre 2024, s’inscrit dans une compétition intense autour des assistants de programmation. GitLab revendique 30 millions d’utilisateurs enregistrés et occupe une place importante dans le DevSecOps, une approche qui rapproche développement, exploitation et sécurité. Face à lui, GitHub Copilot, porté par Microsoft, a largement popularisé l’assistance au code par IA. L’enjeu ne se limite donc pas à suggérer quelques lignes dans un éditeur : il consiste à faire de l’IA un outil présent à chaque étape du cycle de vie d’un logiciel.

Ce que réunit le partenariat entre AWS et GitLab

GitLab Duo est intégré à la plateforme GitLab, utilisée pour héberger le code, gérer les demandes de fusion, automatiser les tests et suivre les livraisons. Amazon Q Developer est, de son côté, l’assistant d’AWS destiné aux développeurs. Le rapprochement des deux services doit permettre de mobiliser les agents d’Amazon directement dans l’environnement GitLab.

La distinction entre un assistant de code classique et un agent est importante. Un assistant peut proposer une fonction, compléter une instruction ou expliquer un fichier. Un agent vise à accomplir une tâche plus large à partir d’une consigne : examiner le contexte d’un projet, produire une modification, générer des tests et préparer une proposition de changement. Dans le cas présenté par AWS et GitLab, l’objectif est notamment de créer du code prêt à être soumis sous la forme d’une demande de fusion, aussi appelée merge request.

La demande de fusion est l’un des mécanismes centraux du travail collectif. Elle permet à un développeur de proposer une évolution du code, puis à ses collègues de l’examiner avant son intégration dans la branche principale du projet. Automatiser une partie de sa préparation peut faire gagner du temps, surtout pour les correctifs répétitifs ou les chantiers de modernisation bien cadrés.

Cette promesse d’intégration est au cœur de la stratégie. Plutôt que de demander aux équipes de passer d’un outil de génération de code à un outil de test, puis à un outil de sécurité et à une plateforme de collaboration, les partenaires entendent réunir davantage de fonctions au même endroit.

Pourquoi la réduction du nombre d’outils est-elle un enjeu ?

La multiplication des logiciels est un problème très concret pour les organisations techniques. Chaque outil supplémentaire peut nécessiter une configuration, des droits d’accès, une formation, des connecteurs et une maintenance. Il peut aussi isoler des informations utiles, par exemple lorsqu’un résultat de sécurité ne remonte pas dans l’interface où se déroule la revue du code.

GitLab cite une étude selon laquelle 54 % des développeurs utilisent jusqu’à 14 outils différents dans leur travail de développement. Ce chiffre illustre la fragmentation à laquelle répond le partenariat. L’idée n’est pas seulement de rendre les développeurs plus rapides. Elle est aussi de limiter les ruptures dans le parcours qui mène d’une idée au code mis en production.

Dans une démarche DevSecOps, la sécurité ne doit pas arriver uniquement à la fin, juste avant une livraison. Elle est intégrée plus tôt, lors de l’écriture et de la revue du code. Des analyses alimentées par l’IA peuvent ainsi signaler des problèmes de qualité ou de sécurité au moment où une modification est proposée, lorsque son auteur dispose encore du contexte nécessaire pour la corriger.

Qui peut tester l’intégration et dans quelles conditions ?

Au moment de la publication, l’offre est disponible en preview pour les clients de GitLab Ultimate utilisant une installation Self-Managed, c’est-à-dire auto-hébergée. Cette précision compte : il ne s’agit pas encore d’une disponibilité générale pour tous les utilisateurs de GitLab, ni d’une fonction automatiquement accessible à toutes les formules de l’éditeur.

L’auto-hébergement consiste pour une organisation à exploiter GitLab dans son propre environnement informatique, plutôt que de confier l’hébergement du service à GitLab.com. Ce choix est courant dans les grandes entreprises et les administrations qui souhaitent garder la maîtrise de l’emplacement de leurs données, de leurs configurations et de leurs règles d’accès.

La phase de preview permet de confronter les promesses de l’intégration aux réalités des projets. Les équipes devront notamment évaluer la qualité des propositions produites par les agents, la pertinence des tests générés, la capacité de l’outil à comprendre leur base de code et sa compatibilité avec leurs politiques internes. Les gains annoncés ne se mesurent pas uniquement au nombre de lignes écrites : ils dépendent aussi du temps passé à vérifier, ajuster ou rejeter les suggestions de l’IA.

Tests, qualité et sécurité : ce que les agents doivent apporter

Les capacités mises en avant par AWS et GitLab couvrent plusieurs tâches traditionnellement coûteuses. Les agents d’Amazon Q doivent pouvoir générer du code à partir d’une demande, tout en apportant des retours pendant le processus de revue. Les analyses pilotées par l’IA sont présentées comme un moyen d’évaluer en temps réel la qualité et la sécurité du code.

La génération de tests unitaires est un autre élément central. Ces tests vérifient le comportement de petites unités de programme, comme une fonction ou une méthode. Ils ne garantissent pas à eux seuls qu’une application entière fonctionne correctement, mais ils constituent une première protection contre les régressions, ces erreurs qui apparaissent lorsqu’une modification casse une fonctionnalité existante.

L’intérêt d’intégrer ces fonctions à une demande de fusion est opérationnel. Les informations utiles, code modifié, commentaires, résultats des contrôles et tests, se retrouvent dans le même flux de collaboration. Les développeurs peuvent alors traiter un retour avant que le changement ne rejoigne le projet principal.

Ashley Kramer, directrice marketing et stratégie de GitLab, met en avant un parcours continu allant de la validation du code à la production, dans un environnement conçu pour être sécurisé et fiable. Cette continuité résume le positionnement des deux entreprises : faire de l’IA une composante du processus, et non un service isolé auquel le développeur recourt ponctuellement.

La migration vers Java 17, un usage concret de l’IA

Parmi les fonctionnalités annoncées, la possibilité de faire évoluer des bases de code de Java 8 ou Java 11 vers Java 17 est particulièrement révélatrice. Pour de nombreuses organisations, les mises à niveau de langage ou de plateforme sont nécessaires mais difficiles à prioriser. Elles impliquent souvent de modifier un grand nombre de fichiers, de vérifier des dépendances et de résoudre des incompatibilités.

Java 17 constitue une version importante de l’écosystème Java. Migrer vers une version plus récente peut aider une entreprise à réduire sa dette technique, cette accumulation de choix anciens qui rend un logiciel plus difficile à maintenir. Cela peut également contribuer à renforcer la sécurité et la pérennité des applications, à condition que la migration soit effectivement vérifiée dans le contexte propre à chaque projet.

Un agent peut être utile pour accélérer les transformations répétitives, proposer des modifications et préparer des tests. Mais une modernisation réussie exige une validation attentive. Les applications Java complexes peuvent dépendre de bibliothèques anciennes, de comportements spécifiques ou d’infrastructures qui ne se prêtent pas à une conversion automatique sans contrôle.

Face à GitHub Copilot, deux stratégies d’assistance au code

Cette collaboration place AWS et GitLab face à un concurrent majeur. GitHub s’appuie sur une communauté de plus de 100 millions de développeurs et sur GitHub Copilot, qui a contribué à installer l’IA générative dans les habitudes de programmation. La réponse d’AWS et GitLab mise moins sur une simple fonction de complétion que sur l’intégration d’agents dans un environnement DevSecOps complet.

GitHub ne reste pas immobile. La plateforme a élargi les choix de modèles d’IA disponibles dans son offre Copilot, avec notamment Claude 3.5 d’Anthropic et Gemini 1.5 Pro de Google. Cette approche donne aux utilisateurs davantage de souplesse pour sélectionner un système adapté à leurs besoins, à leurs préférences ou à la nature de leurs tâches.

GitHub a aussi présenté GitHub Spark, un outil conçu pour créer des « micro-applications » à partir d’instructions en langage naturel. Cette orientation vise des personnes moins familières avec la programmation traditionnelle. Son adoption dépendra toutefois de la manière dont le produit sera accompagné et intégré dans l’écosystème de Microsoft, propriétaire de GitHub.

Une concurrence qui dépasse la simple génération de code

Comparer ces offres uniquement sur la capacité à écrire une fonction serait réducteur. Les entreprises évaluent aussi la protection de leur code, l’administration des accès, l’intégration avec leurs procédures de livraison, le choix des modèles et la possibilité de conserver leurs outils existants. AWS possède une place centrale dans le cloud d’entreprise, tandis que GitLab cherche à faire de sa plateforme le point de convergence des équipes de développement, de sécurité et d’exploitation.

L’offre AWS et GitLab peut séduire les organisations déjà équipées de GitLab Ultimate en auto-hébergement et présentes dans l’écosystème AWS. Pour elles, l’intérêt potentiel est de réduire les frictions entre les services plutôt que d’ajouter une nouvelle interface. À l’inverse, les équipes très ancrées dans GitHub peuvent privilégier les avancées de Copilot et la diversité de modèles désormais proposée par la plateforme.

Dans les deux cas, l’IA transforme le rôle du développeur sans le faire disparaître. Le travail se déplace en partie : moins de temps sur certaines tâches répétitives, davantage d’attention sur la formulation des demandes, l’examen des propositions, l’architecture, les tests pertinents et les conséquences d’un changement sur l’ensemble du produit.

Ce qu’il faut surveiller

La première question sera celle du passage de la preview à une disponibilité plus large. Les conditions d’accès, l’étendue des environnements pris en charge et les retours des premiers clients détermineront la portée effective du partenariat entre AWS et GitLab.

Il faudra ensuite regarder la fiabilité des agents dans des bases de code réelles. Générer une demande de fusion en quelques minutes est utile seulement si les modifications sont compréhensibles, testables et suffisamment adaptées au contexte de l’entreprise. La qualité des analyses de sécurité, la pertinence des tests unitaires et la capacité à traiter les migrations Java seront des indicateurs plus parlants que la seule vitesse de production.

Enfin, le duel avec GitHub Copilot devrait se jouer sur l’écosystème. GitLab et AWS défendent une plateforme intégrée associant collaboration, sécurité et agents. GitHub mise sur sa très vaste communauté, sur Copilot et sur l’ouverture à plusieurs modèles d’IA. Pour les développeurs, cette compétition peut se traduire par davantage de choix. Pour les entreprises, elle impose surtout de définir avec précision où l’IA apporte une aide réelle, et où le contrôle humain doit rester incontournable.