Pour construire la bonne stack d'IA générative pour l'ingénierie logicielle, traitez l'IA comme un système en couches : utilisez des assistants de codage pour le travail de code local, ajoutez une couche de contexte partagée qui relie le code aux tickets, incidents, documents et responsabilités, et intégrez des outils d'incident et des agents autour de cette base.
Les équipes d'ingénierie logicielle ne se demandent plus si elles doivent utiliser l'IA. Elles cherchent à savoir comment la rendre utile en production. Des technologies d'IA générative comme GitHub Copilot ont intégré l'IA dans les workflows quotidiens, mais aider les ingénieurs à écrire du code plus vite ne résout pas le problème plus difficile — obtenir le bon contexte, les bons garde-fous et le bon support de workflow autour du code pour permettre aux équipes de livrer en toute sécurité et de façon fiable.
Le véritable goulot d'étranglement pour la plupart des équipes, c'est la reconstitution du contexte. Les ingénieurs perdent encore des heures à retrouver des documents d'architecture, des tickets Jira, l'historique d'incidents, les informations de ownership, les fils Slack et les runbooks dans des systèmes qui ne communiquent pas naturellement entre eux. Une stack qui comble cet écart vaut la peine d'être construite. Une stack qui ajoute simplement un onglet de plus, non.
La meilleure stack d'IA générative pour les ingénieurs logiciels combine assistants de codage, systèmes de contexte, outils d'observabilité et gouvernance d'une manière qui s'adapte à la façon dont le travail d'ingénierie se déroule réellement.
Trois écarts qui freinent les premiers déploiements d'IA
Les engineering managers constatent généralement trois écarts récurrents lors de l'adoption de technologies d'IA générative via des assistants de codage :
Résultat – L'IA paraît plus rapide, mais génère du travail de reprise en aval. Dans un essai contrôlé randomisé de METR mené auprès de développeurs expérimentés de logiciels open source, les tâches réalisées avec l'IA ont pris 19 % de temps en plus — alors que les participants s'attendaient à être 24 % plus rapides et pensaient malgré tout, après coup, que l'IA les avait aidés.
Confiance – Les suggestions sont suffisamment proches pour sembler correctes, mais nécessitent quand même une vérification poussée. Dans le Stack Overflow Developer Survey 2025, davantage de développeurs se méfiaient activement de la précision de l'IA qu'ils ne lui faisaient confiance, et 66 % citaient comme principale frustration du code « presque juste, mais pas tout à fait ».
Sécurité – Des garde-fous faibles augmentent la surface d'attaque. Dans le 2025 Veracode GenAI code security report, près de 45 % des échantillons de code générés par l'IA contenaient au moins une vulnérabilité de sécurité de gravité élevée.
Une meilleure génération de code par le modèle aide. Mais ces écarts ne se comblent pas avec un meilleur modèle. Ils se comblent avec un meilleur système de contexte autour de lui.
Quatre catégories d'outils d'IA dans la stack d'IA d'ingénierie
La manière la plus claire de planifier votre stack consiste à penser en termes de quatre missions distinctes que vos outils doivent remplir tout au long du processus de développement logiciel :
1. Assistants pour la génération de code locale
Les outils natifs de l'IDE comme Cursor, GitHub Copilot, Claude Code, Windsurf, Codeium et Sourcegraph Cody gèrent la génération de code inline, le refactoring, la génération de tests, la détection de bugs et le debug localisé. Ils aident les développeurs individuels à écrire du code plus vite dans un dépôt ou un espace de travail, et la plupart des équipes en ont déjà un en place.
Leur limite, c'est la visibilité sur le système environnant. Un assistant de codage qui ne dispose que du contexte du dépôt n'a aucune connaissance du ticket Jira à l'origine du changement, de l'incident qui a révélé la régression, du document d'architecture qui a fixé les contraintes, ni du fil Slack où l'équipe a décidé de son approche. 41 % des développeurs logiciels disent que leur principal frein à la productivité est une information obsolète, incohérente ou cloisonnée.
2. Une plateforme de contexte qui comprend le travail d'ingénierie
Une plateforme de contexte relie les artefacts et les personnes derrière le code. Elle met en relation les hébergeurs de code, le suivi du travail, les documents, les conversations, les incidents et les traces d'observabilité dans une vue partagée et sensible aux droits d'accès de l'environnement d'ingénierie — afin qu'un ingénieur puisse demander « Qu'est-ce qui a cassé la dernière fois que cette alerte s'est déclenchée ? » ou « Qui est responsable de cet endpoint maintenant ? » et obtenir une réponse fondée sur des artefacts réels plutôt qu'une supposition plausible.
C'est la couche dont beaucoup d'entreprises découvrent avoir besoin une fois que l'IA générative dans le développement logiciel passe du stade d'expérimentation à l'usage quotidien. Dans le State of Developer Experience Report d'Atlassian, 62 % des développeurs ont déclaré que la reconstitution du contexte à travers plusieurs outils les ralentissait.
Glean est conçu pour ce rôle. Il construit un système de contexte partagé à travers des outils comme GitHub, Jira, Confluence, Slack et Teams, en s'appuyant sur son Enterprise Graph pour relier services, incidents, tickets, responsables et artefacts de conception. Comme Glean hérite des permissions des systèmes sources et les applique, les réponses restent dans les limites d'accès déjà disponibles pour les ingénieurs.
3. L'IA d'observabilité pour les signaux d'incident
L'IA d'observabilité sait ce que disent les métriques. Elle peut résumer les alertes, les traces et les logs, regrouper les signaux associés et mettre en avant les régressions probables — tout cela aide à améliorer la productivité des développeurs et à réduire le temps moyen de résolution. En revanche, elle ne peut pas vous dire quel ticket Jira a modifié le service, ce que le document d'architecture précisait, qui a approuvé le déploiement, ni comment un incident similaire a été résolu il y a six mois. Associer des outils d'incident à une plateforme de contexte comble ces lacunes et transforme le triage, d'un exercice de lecture de logs, en une investigation transversale entre systèmes.
4. Plateformes d'agents et hubs de modèles
Les plateformes d'IA généralistes et les frameworks d'agents — y compris les fournisseurs de grands modèles de langage et les runtimes d'orchestration — offrent aux équipes le choix du modèle, le support d'exécution des agents et l'orchestration des workflows. Elles facilitent le prototypage d'assistants et leur connexion aux autres technologies de la stack.
Ce qu'elles ne fournissent pas à elles seules, c'est un contexte d'ingénierie partagé : des intégrations entre code, tickets, incidents et documents, ainsi qu'une vue cohérente et sensible aux droits d'accès à travers les systèmes. Les plateformes d'agents ne sont utiles que dans la mesure où les données, la structure et la gouvernance que vous y raccordez le sont — c'est pourquoi elles fonctionnent mieux lorsqu'elles peuvent s'appuyer sur une couche de contexte partagée plutôt que de reconstruire chacune leur propre vue partielle.
Des quatre catégories d'outils à deux couches architecturales
Ces quatre catégories d'outils se résument à un modèle architectural plus simple : une couche qui comprend le travail (contexte), et une couche où les ingénieurs réalisent le travail (codage et surfaces d'interaction).
La couche de contexte se connecte aux hébergeurs de code, à Jira, aux systèmes d'incidents, aux outils d'observabilité, aux documents, aux wikis et aux conversations. Elle indexe ces systèmes, relie les artefacts associés, respecte les permissions et offre aux ingénieurs un moyen fiable d'assembler le contexte sur l'ensemble du cycle de vie du développement logiciel.
Une couche de contexte utile devrait être capable de répondre à des questions telles que :
- Quels dépôts, tickets, incidents et responsables sont liés à ce service ?
- Qu'est-ce qui a changé avant l'apparition de ce problème ?
- Quels documents de conception et quelles décisions antérieures restent pertinents ici ?
- Qui doit examiner ou approuver l'étape suivante ?
La couche de codage et d'interaction est l'endroit où les ingénieurs passent leur temps. Elle comprend l'IDE, l'hébergeur de code, le suivi du travail, les consoles d'incidents et les outils de collaboration. Ce sont les surfaces où le code est modifié, où les revues ont lieu, où les incidents sont résolus et où le travail progresse.
Le point essentiel est que les surfaces de codage et d'interaction ne devraient pas avoir à reconstruire le contexte pour chaque requête. Lorsque chaque assistant crée sa propre vue partielle du monde, les ingénieurs obtiennent des réponses incohérentes, un travail de sécurité dupliqué et davantage de dispersion de l'IA.
Évaluez chaque outil à l'aune de ces questions
L'ensemble de la pile IA repose sur des technologies qui évoluent rapidement. Avant d'ajouter un autre outil GenAI à la pile, recentrez la discussion autour de ces quatre questions :
Quel contexte a-t-il réellement ?
« Context-aware » peut vouloir dire presque n'importe quoi. Un outil qui ne voit que le fichier ou le dépôt actuel manquera les tickets, incidents, documents, responsables et contraintes qui façonnent les véritables décisions d'ingénierie. Un outil plus puissant peut suivre la chaîne depuis l'alerte jusqu'au ticket, puis au changement de code, au responsable et à l'incident antérieur, sans qu'un humain ait à tout relier. La profondeur d'accès à vos systèmes d'ingénierie détermine la qualité de chaque réponse générée par l'IA, et ce contexte compte plus que les seules données d'entraînement du modèle.
Comment la confiance est-elle gagnée, et non présumée ?
Les ingénieurs font confiance aux systèmes qui montrent leur travail — des réponses fondées sur des artefacts réels, reliées aux sources et faciles à vérifier. Si les personnes doivent encore refaire l'enquête pour confirmer la réponse, l'adoption ralentit et les gains en qualité de code disparaissent. Glean fonde chaque réponse sur votre propre code, vos tickets, vos documents et vos discussions, avec des liens sources pour que les ingénieurs puissent inspecter directement les preuves.
Où vont vos données, et qui peut agir dessus ?
Dès que l'IA peut lire le code source, les incidents et les tickets — et surtout dès qu'elle peut agir — vous prenez une décision de sécurité et de gouvernance. Cela signifie qu'il faut comprendre où résident les index, si les permissions sont héritées des systèmes sources, comment fonctionne l'audit et si l'outil opère dans les contrôles exigés par votre équipe sécurité. Glean prend en charge des options de déploiement single-tenant sur AWS, Azure ou GCP, avec une application stricte des permissions et une auditabilité intégrées.
Est-ce adapté à la façon dont vos équipes travaillent déjà ?
Les outils les plus performants s'intègrent dans les workflows existants, et non à côté. Une pile pratique doit s'intégrer proprement avec GitHub ou GitLab, Jira, Slack ou Teams, les outils d'observabilité, l'IDE — et vous permettre de commencer par les besoins spécifiques d'une seule équipe de développement avant de passer à l'échelle.
Concevez la pile autour de workflows réels
Une bonne architecture d'ingénierie est bien plus facile à évaluer lorsque vous observez des workflows courants plutôt que des fonctionnalités abstraites.
L'onboarding et la compréhension d'un service doivent commencer par le contexte
Les nouveaux ingénieurs ont rarement des difficultés parce qu'il n'y a pas de code. Ils peinent parce que le code est entouré d'une histoire dispersée : le document de conception est dans un wiki, le propriétaire du service a changé deux fois, le dernier incident est enfoui dans Slack, et la traçabilité dans Jira est incomplète. Selon les recherches de GitLab, près de la moitié (44 %) des organisations indiquent que l'intégration de nouveaux développeurs logiciels prend plus de deux mois.
C'est le problème qu'une couche de contexte résout. Lorsque la pile relie la propriété des services, les documents, les incidents et l'historique du code, l'onboarding devient plus rapide et moins dépendant de la connaissance tacite. GitLab a également constaté que 43 % des développeurs utilisant l'IA pour le développement logiciel ont réduit le temps d'onboarding à moins d'un mois. Avec Glean, par exemple, un nouvel ingénieur peut demander une vue d'ensemble d'un service et obtenir en retour les documents de conception pertinents, les incidents récents, les propriétaires actuels et les tickets associés — rassemblés à partir d'artefacts et de documentation réels, et non d'un résumé qu'une personne aurait pensé à mettre à jour.
Les changements courants doivent utiliser l'IA avec des garde-fous
L'IA générative gère déjà bien les tâches d'ingénierie logicielle répétitives et de faible portée : ajustements de configuration, génération de cas de test, mises à jour de documentation, correctifs simples, refactorisations incrémentales. Mais même les changements courants nécessitent les exigences et contraintes environnantes.
Les équipes matures se concentrent sur la définition de classes de changements claires pour lesquelles l'IA est autorisée à proposer des modifications — changements de niveau de logs, certaines mises à jour de configuration, refactorisations sans impact sur le comportement, documentation et tests — et considèrent les tickets liés, les documents de conception et les commentaires issus du contexte partagé comme des garde-fous. L'assistant de codage rédige le patch la couche de contexte agit comme un contrôle qualité, en vérifiant que le patch correspond au ticket, aux contraintes du service et aux exigences de qualité de code pour ce chemin de code.
La réponse aux incidents doit combiner les signaux avec un contexte inter-systèmes
Pendant un incident, les trois questions urgentes sont : qu'est-ce qui a changé, qu'est-ce qui est en échec, et qui doit être impliqué ? L'IA d'observabilité peut résumer les signaux. Une plateforme de contexte relie ces signaux aux changements de code récents, aux tickets associés, aux responsables, aux incidents antérieurs et aux documents pertinents — afin que l'équipe ne reconstruise pas l'histoire à partir de zéro pendant une panne.
LinkedIn a construit un agent threat-bot propulsé par Glean précisément pour ce type de triage inter-systèmes et a économisé 2,4 M$ par an en temps d'ingénierie. L'équipe d'ingénierie d'Uber a constaté une réduction de 20 % du temps de mise en production du code après avoir adopté Glean comme plateforme de contexte.
Glean : la fondation de contexte pour le reste de la pile
Glean s'intègre dans ce schéma comme la couche de contexte partagée qui aide le reste de la pile pilotée par l'IA à travailler à partir du même ensemble de faits.
Glean connecte les sources de données d'ingénierie — hébergeurs de code, Jira, documents et wikis, chat, incidents, systèmes adjacents à l'observabilité — et construit un système de contexte partagé, en utilisant son Enterprise Graph pour relier les personnes, le contenu et le travail. Les ingénieurs peuvent rechercher et raisonner à travers la pile réelle au lieu de passer d'un outil déconnecté à l'autre. Les assistants de codage peuvent intégrer ce contexte dans l'éditeur via MCP, afin que les suggestions soient fondées sur le système global, et pas seulement sur le fichier ouvert.
Cette approche fait déjà ses preuves. Deux des trois plus grandes organisations utilisant des assistants de codage s'appuient déjà sur Glean pour alimenter la couche de contexte derrière leurs plateformes d'ingénierie.
La pile d'IA générative continuera d'évoluer. Les équipes changeront d'assistants de codage, testeront de nouveaux modèles et feront évoluer leurs technologies de workflow. Une couche de contexte stable et gouvernée sous-jacente à ces évolutions est ce qui empêche votre pile de se fragmenter à chaque nouvelle sortie — et donne aux futurs outils les mêmes données de confiance fondation dès le premier jour. Glean est conçu pour ce rôle : agnostique au modèle, ouvert aux assistants de codage et aux frameworks d'agents que votre architecture inclut déjà, et conçu pour que vous indexiez une fois et réutilisiez ce contexte sur chaque surface.
Construisez la stack délibérément, pas outil par outil
La conversation sur l'application de l'IA générative à l'ingénierie logicielle a dépassé la question « Quel copilote est le meilleur ? » La vraie question est désormais : quelle stack aide vos développeurs logiciels à aller plus vite sans créer davantage de retouches, de problèmes de confiance ou d'exposition de sécurité ?
Pour la plupart des organisations, la réponse est une approche en couches : des assistants de codage pour le travail local, un contexte partagé reliant les systèmes d'ingénierie, de l'IA pour les incidents et l'observabilité pour les workflows à forte empreinte de télémétrie, et des plateformes d'agents pour orchestrer les tâches au-dessus de cette fondation. Les organisations qui construisent ainsi mesurent déjà des gains de performance d'équipe en temps de cycle, vitesse d'onboarding, qualité du code et résolution des incidents.
Obtenez le cadre complet
Pour connaître le paysage complet des outils, un examen détaillé du modèle à deux couches, des exemples concrets et les priorités d'évaluation que les responsables d'ingénierie devraient utiliser avant de déployer les technologies d'IA générative à grande échelle sur l'ensemble du cycle de développement logiciel, lisez Le guide de terrain de l'ingénieur logiciel sur la stack IA.
Foire aux questions
Qu'est-ce que MCP et comment relie-t-il les assistants de codage à une couche de contexte ?
MCP (Model Context Protocol) est une norme ouverte qui permet aux outils alimentés par l'IA, y compris les assistants de codage basés sur de grands modèles de langage, d'accéder à des sources de données externes pendant une session. Un assistant de codage comme Cursor ou Claude Code peut interroger une plateforme de contexte en cours de tâche — en récupérant des tickets, des incidents, la propriété ou des documents de conception — sans quitter l'éditeur. Glean prend en charge MCP afin que les assistants compatibles puissent appeler la même couche de contexte partagée qui alimente la recherche Glean, Assistant et les agents.
Comment protéger le code source et les données internes lors de l'utilisation d'outils de codage IA ?
Posez trois questions : où résident les données, qui peut les voir et qu'est-ce qui est journalisé ? Tout outil d'IA générative qui indexe du code source ou des documents internes doit appliquer les mêmes contrôles d'accès que les systèmes sources. Recherchez une architecture mono-tenant, un déploiement cloud contrôlé par le client et une journalisation d'audit exploitable par votre équipe sécurité. Glean fonctionne dans un environnement cloud mono-tenant, hérite et applique les permissions des systèmes sources, et prend en charge l'auditabilité attendue par les équipes d'entreprise.
Par où une équipe d'ingénierie devrait-elle commencer pour construire une stack IA ?
Commencez par ce que vous avez. La plupart des équipes utilisent déjà un assistant de codage. L'étape suivante la plus rentable consiste à ajouter une couche de contexte reliant tickets, incidents, documents et responsabilités au code. Choisissez une équipe de développement ou un workflow, mesurez les progrès en temps de cycle et en retouches, puis élargissez à partir de là.
Ai-je besoin d'une plateforme de contexte ou puis-je en construire une avec RAG et des outils internes ?
Un pipeline RAG de base vous donne une recherche sémantique sur un sous-ensemble de vos données. Ce qu'il ne vous donne pas, c'est un graphe d'entreprise relié, l'application des permissions du système source ou une surface gouvernée à laquelle plusieurs assistants et agents peuvent se connecter. La plupart des équipes qui commencent avec du RAG interne finissent par reconstruire la logique de permissions et maintenir des pipelines de connecteurs sur des dizaines de systèmes. Une plateforme conçue à cet effet comme Glean prend en charge cette infrastructure.
Comment mesurer si une stack d'IA pour l'ingénierie fonctionne vraiment ?
Mesurez le temps de cycle, le taux de retouches, le temps d'onboarding, le temps moyen de résolution et la fréquence des changements de contexte — pas seulement les chiffres d'adoption. Les ingénieurs seniors et les responsables d'équipe devraient suivre ces métriques par rapport à une base de référence. Si le temps de cycle baisse mais que les retouches augmentent, la stack produit du code plus vite sans les bons garde-fous. Si le temps d'onboarding diminue et que les équipes livrent toujours du code de haute qualité, la couche de contexte fonctionne. L'objectif est une livraison plus rapide et plus sûre sur l'ensemble du workflow, pas seulement une production plus rapide sur les tâches répétitives.
Combien de temps faut-il pour connecter Glean à une stack d'ingénierie existante ?
Les connecteurs de Glean couvrent les plateformes d'ingénierie les plus courantes — notamment GitHub, GitLab, Jira, Confluence, Slack, Teams, PagerDuty et Datadog — avec des permissions héritées et une synchronisation en temps réel entre les systèmes. La plupart des organisations commencent par un workflow ou une équipe, puis étendent ensuite.
