Pour construire la bonne stack d'IA générative pour l'ingénierie logicielle, considérez l'IA comme un système en couches : utilisez des assistants de codage pour le travail local sur le code, ajoutez une couche de contexte partagé qui relie le code aux tickets, incidents, documents et à la propriété, puis intégrez des outils de gestion d'incidents et d'agents autour de cette fondation.
Les équipes d'ingénierie logicielle ne se demandent plus si elles doivent utiliser l'IA. Elles cherchent à la rendre utile en production. Les technologies d'IA générative comme GitHub Copilot ont intégré l'IA aux flux de travail quotidiens, mais aider les ingénieurs à écrire du code plus vite ne résout pas le problème le plus difficile : fournir le bon contexte, les garde-fous et le soutien aux flux de travail autour du code pour que les équipes puissent livrer en toute sécurité et fiabilité.
Le véritable goulot d'étranglement pour la plupart des équipes est la reconstruction du contexte. Les ingénieurs perdent encore des heures à chercher des documents de conception, des tickets Jira, l'historique des incidents, les registres de propriété, les fils de discussion Slack et les runbooks à travers des systèmes qui ne communiquent pas naturellement entre eux. Une stack qui comble cet écart vaut la peine d'être construite. Une qui ajoute un énième onglet déconnecté, 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 correspond à la réalité du travail d'ingénierie.
Trois lacunes qui freinent les premiers déploiements d'IA
Les responsables d'ingénierie observent généralement trois lacunes récurrentes lors de l'adoption des technologies d'IA générative via les assistants de codage :
Résultats – L'IA semble plus rapide, mais génère du travail à refaire en aval. Dans un essai contrôlé randomisé de METR auprès de développeurs open source expérimentés, les tâches réalisées avec l'IA ont pris 19 % de temps en plus — alors même que les participants s'attendaient à être 24 % plus rapides et croyaient encore ensuite que l'IA les avait aidés.
Confiance – Les suggestions tombent suffisamment juste pour paraître correctes, mais nécessitent tout de même une vérification approfondie. Dans la 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 le code « presque juste, mais pas tout à fait » comme leur plus grande frustration.
Sécurité – Des garde-fous faibles augmentent la surface d'attaque. Dans le rapport Veracode 2025 sur la sécurité du code GenAI, près de 45 % des échantillons de code générés par IA contenaient au moins une vulnérabilité de sécurité de haute gravité.
Une meilleure génération de code par le modèle aide. Mais ces lacunes ne se comblent pas avec un meilleur modèle. Elles 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 façon la plus claire de planifier votre stack est de raisonner en termes de quatre tâches distinctes que vos outils doivent accomplir tout au long du processus de développement logiciel :
1. Des assistants pour la génération de code local
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 de code, la génération de tests, la détection de bogues et le débogage localisé. Ils aident les développeurs à écrire du code plus vite au sein d'un dépôt ou d'un espace de travail, et la plupart des équipes en ont déjà un en place.
Là où ils atteignent leurs limites, c'est dans la visibilité sur le système environnant. Un assistant de codage travaillant uniquement à partir du contexte du dépôt n'a aucune conscience du ticket Jira qui a motivé le changement, de l'incident qui a signalé la régression, du document de conception qui a fixé les contraintes, ou du fil de discussion Slack où l'équipe a décidé de son approche. 41 % des développeurs logiciels affirment que leur plus grande perte de productivité provient d'informations obsolètes, incohérentes ou cloisonnées.
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 connecte les hébergeurs de code, le suivi des tâches, les documents, la messagerie, les incidents et les traces d'observabilité dans une vue partagée et respectueuse des permissions de l'environnement d'ingénierie — pour 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 ce point de terminaison maintenant ? » et obtenir une réponse fondée, construite à partir d'artefacts réels plutôt qu'une supposition plausible.
C'est la couche dont de nombreuses entreprises découvrent le besoin une fois que l'IA générative dans le développement logiciel passe de l'expérimentation à l'usage quotidien. Dans le State of Developer Experience Report d'Atlassian, 62 % des développeurs ont déclaré que la reconstruction du contexte entre 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 utilisant son Graphe d'entreprise pour relier services, incidents, tickets, responsables et artefacts de conception. Parce que Glean hérite et applique les permissions des systèmes sources, les réponses restent dans les limites d'accès dont disposent déjà 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 journaux, regrouper les signaux liés et mettre en évidence les régressions probables — autant d'éléments qui contribuent à améliorer la productivité des développeurs et à réduire le temps moyen de résolution. Ce qu'elle ne peut pas vous dire, c'est quel ticket Jira a modifié le service, ce que spécifiait le document de conception, qui a approuvé le déploiement, ou comment un incident similaire a été résolu il y a six mois. Associer les outils de gestion d'incidents à une plateforme de contexte comble ces lacunes et transforme le triage, d'un exercice de lecture de journaux, en une véritable investigation inter-systèmes.
4. Plateformes d'agents et hubs de modèles
Les plateformes d'IA polyvalentes 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, la prise en charge du runtime d'agents et l'orchestration des flux de travail. Ils facilitent le prototypage d'assistants et leur connexion aux autres technologies de la stack.
Ce qu'ils ne fournissent pas à eux seuls, c'est un contexte d'ingénierie partagé : des intégrations entre le code, les tickets, les incidents et les documents, ainsi qu'une vue cohérente et respectueuse des permissions à travers les systèmes. Les plateformes d'agents ne valent que par les données, la structure et la gouvernance que vous y intégrez — c'est pourquoi elles fonctionnent le mieux lorsqu'elles peuvent faire appel à une couche de contexte partagé plutôt que de reconstruire chacune sa propre vue partielle.
De quatre catégories d'outils à deux couches architecturales
Ces quatre catégories d'outils correspondent à un modèle architectural plus simple : une couche qui comprend le travail (le contexte), et une couche où les ingénieurs réalisent le travail (les surfaces de codage et d'interaction).
La couche de contexte se connecte aux hébergeurs de code, à Jira, aux systèmes de gestion d'incidents, aux outils d'observabilité, aux documents, aux wikis et à la messagerie. Elle indexe ces systèmes, relie les artefacts connexes, respecte les permissions et offre aux ingénieurs un moyen unique et fiable d'assembler le contexte tout au long du cycle de vie du développement logiciel.
Une couche de contexte utile doit être capable de répondre à des questions telles que :
- Quels repos, tickets, incidents et propriétaires sont liés à ce service ?
- Qu'est-ce qui a changé avant l'apparition de ce problème ?
- Quels documents de conception et décisions antérieures restent pertinents ici ?
- Qui doit examiner ou approuver la prochaine étape ?
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 des tâches, les consoles d'incident et les outils de collaboration. C'est sur ces surfaces que le code est modifié, que les revues ont lieu, que les incidents sont résolus et que le travail avance.
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 construit sa propre vision partielle du monde, les ingénieurs obtiennent des réponses incohérentes, un travail de sécurité dupliqué et une prolifération accrue de l'IA.
Évaluez chaque outil en gardant ces questions à l'esprit
L'ensemble de la pile d'IA repose sur des technologies qui évoluent rapidement. Avant d'ajouter un nouvel outil GenAI à la pile, gardez la discussion ancrée autour de ces quatre questions :
De quel contexte dispose-t-il réellement ?
« Contextuel » peut vouloir dire à peu près n'importe quoi. Un outil qui ne voit que le fichier ou le repo en cours passera à côté des tickets, incidents, documents, propriétaires et contraintes qui façonnent les véritables décisions d'ingénierie. Un outil plus robuste peut suivre la chaîne qui va de l'alerte au ticket, du changement de code au propriétaire et à l'incident antérieur, sans qu'un humain ait à tout relier. La profondeur de l'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 bien 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 raisonnement — des réponses ancrées dans des artefacts réels, reliées à leurs sources et faciles à vérifier. Si les gens doivent encore refaire l'investigation pour confirmer la réponse, l'adoption stagne et les gains en qualité de code disparaissent. Glean ancre chaque réponse dans votre propre code, vos tickets, vos documents et vos discussions, avec des liens vers les sources pour que les ingénieurs puissent inspecter les preuves directement.
Où vont vos données, et qui peut agir dessus ?
Dès lors 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 implique de 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 au sein des contrôles exigés par votre équipe de sécurité. Glean prend en charge des options de déploiement mono-locataire sur AWS, Azure ou GCP, avec une application stricte des permissions et une auditabilité intégrées.
S'intègre-t-il à la façon dont vos équipes travaillent déjà ?
Les outils les plus efficaces s'intègrent dans les workflows existants, et non à côté d'eux. 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 vous étendre.
Concevez la pile autour de workflows réels
Une bonne architecture d'ingénierie est bien plus facile à évaluer lorsque vous regardez des workflows courants plutôt que des fonctionnalités abstraites.
L'intégration et la compréhension des services devraient commencer par le contexte
Les nouveaux ingénieurs rencontrent rarement des difficultés par manque de code. Ils peinent parce que le code est entouré d'un historique dispersé : le document de conception se trouve dans un wiki, le propriétaire du service a changé deux fois, le dernier incident est enfoui dans Slack et la piste Jira est incomplète. Selon une étude de GitLab, près de la moitié (44 %) des organisations affirment que l'intégration de nouveaux développeurs logiciels prend plus de deux mois.
C'est le problème que résout une couche de contexte. Lorsque la pile relie la propriété des services, les documents, les incidents et l'historique du code, l'intégration devient plus rapide et moins dépendante des connaissances tacites. GitLab a également constaté que 43 % des développeurs utilisant l'IA pour le développement logiciel ont réduit le temps d'intégration à moins d'un mois. Avec Glean, par exemple, un nouvel ingénieur peut demander un aperçu 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 — assemblés à partir d'artefacts et de documentation réels, et non d'un résumé que quelqu'un a pensé à mettre à jour.
Les changements de routine devraient 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, corrections de bugs simples, refactorisations incrémentales. Mais même les changements de routine ont besoin des exigences et des contraintes qui les entourent.
Les équipes matures se concentrent sur la définition de classes de changement claires où l'IA est autorisée à proposer des modifications — changements de niveau de journalisation, certaines mises à jour de configuration, refactorisations non comportementales, documentation et tests — et traitent les tickets liés, les documents de conception et les commentaires issus du contexte partagé comme des garde-fous. L'assistant de codage écrit le correctif ; la couche de contexte agit comme un contrôle d'assurance qualité, confirmant que le correctif correspond au ticket, aux contraintes du service et aux attentes de qualité de code pour ce chemin de code.
La réponse aux incidents devrait combiner les signaux avec un contexte inter-systèmes
Lors d'un incident, les trois questions urgentes sont : qu'est-ce qui a changé, qu'est-ce qui échoue 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 propriétaires, aux incidents antérieurs et aux documents pertinents — afin que l'équipe n'ait pas à reconstruire l'histoire à partir de zéro pendant une panne.
LinkedIn a conçu un agent threat-bot propulsé par Glean pour exactement ce type de triage inter-systèmes et a économisé 2,4 M$ de temps d'ingénierie par an. L'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 base de contexte pour le reste de la pile
Glean s'inscrit dans ce tableau comme la couche de contexte partagé qui aide le reste de la pile propulsée par l'IA à travailler à partir du même ensemble de faits.
Glean relie les sources de données d'ingénierie — hébergeurs de code, Jira, documents et wikis, chat, incidents, systèmes proches de 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é à un autre. Les assistants de codage peuvent intégrer ce contexte dans l'éditeur via MCP, de sorte que les suggestions sont ancrées dans le système au sens large, et non seulement dans le fichier ouvert.
Cette approche fait déjà ses preuves. Deux des trois plus grandes organisations d'assistants de codage s'appuient déjà sur Glean pour alimenter la couche de contexte derrière leurs plateformes d'ingénierie.
La stack d'IA générative ne cessera d'évoluer. Les équipes changeront d'assistants de codage, testeront de nouveaux modèles et renouvelleront leurs technologies de workflow. Une couche de contexte stable et encadrée, sous-jacente à ces changements, est ce qui empêche votre stack de se fragmenter à chaque nouvelle mise en service — et offre aux futurs outils la même base de confiance dès le premier jour. Glean est conçu pour ce rôle : agnostique vis-à-vis des modèles, ouvert aux assistants de codage et aux frameworks d'agents que votre architecture intègre déjà, et pensé pour que vous indexiez une seule fois et réutilisiez ce contexte sur toutes les surfaces.
Construisez la stack de façon réfléchie, et non outil par outil
Le débat sur l'application de l'IA générative à l'ingénierie logicielle a dépassé le stade du « Quel copilote est le meilleur ? ». La question est désormais de savoir quelle stack aide vos développeurs à aller plus vite sans générer davantage de reprises, de problèmes de confiance ou d'exposition à la 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, une IA d'incidents et d'observabilité pour les workflows riches en télémétrie, et des plateformes d'agents orchestrant les tâches au-dessus de cette base. Les organisations qui construisent ainsi mesurent déjà des gains de performance de leurs équipes en matière de temps de cycle, de rapidité d'intégration, de qualité du code et de résolution des incidents.
Obtenez le cadre complet
Pour découvrir l'ensemble du paysage 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 à grande échelle les technologies d'IA générative sur l'ensemble du cycle de vie du développement logiciel, lisez Le guide pratique de la stack d'IA pour l'ingénieur logiciel.
Foire aux questions
Qu'est-ce que le MCP et comment relie-t-il les assistants de codage à une couche de contexte ?
Le MCP (Model Context Protocol) est une norme ouverte qui permet aux outils propulsé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 au cours d'une session. Un assistant de codage comme Cursor ou Claude Code peut interroger une plateforme de contexte en pleine tâche — en récupérant des tickets, des incidents, des informations de propriété ou des documents de conception — sans quitter l'éditeur. Glean prend en charge le MCP afin que les assistants compatibles puissent accéder à la même couche de contexte partagée qui alimente la recherche Glean, Assistant et les agents.
Comment sécuriser le code source et les données internes lors de l'utilisation d'outils de codage IA ?
Posez trois questions : où se trouvent les données, qui peut les consulter et qu'est-ce qui est journalisé ? Tout outil d'IA générative qui indexe le code source ou des documents internes devrait appliquer les mêmes contrôles d'accès que les systèmes sources. Recherchez une architecture mono-locataire, un déploiement cloud contrôlé par le client et une journalisation d'audit exploitable par votre équipe de sécurité. Glean s'exécute dans un environnement cloud mono-locataire, hérite et applique les autorisations des systèmes sources, et prend en charge l'auditabilité qu'attendent les équipes d'entreprise.
Par où une équipe d'ingénierie devrait-elle commencer pour construire une stack d'IA ?
Commencez avec ce que vous avez. La plupart des équipes utilisent déjà un assistant de codage. L'étape suivante à plus fort effet de levier est une couche de contexte reliant les tickets, les incidents, les documents et les informations de propriété au code. Choisissez une équipe de développement ou un workflow, mesurez les progrès en termes de temps de cycle et de reprises, puis étendez à partir de là.
Ai-je besoin d'une plateforme de contexte ou puis-je en construire une avec du RAG et des outils internes ?
Un pipeline RAG basique vous offre une recherche sémantique sur une partie de vos données. Ce qu'il ne vous donne pas, c'est un graphe d'entreprise relié, l'application des autorisations des systèmes sources ou une surface encadrée que plusieurs assistants et agents peuvent interroger. La plupart des équipes qui commencent avec un RAG interne finissent par reconstruire la logique d'autorisation et par maintenir des pipelines de connecteurs sur des dizaines de systèmes. Une plateforme dédiée comme Glean gère cette infrastructure.
Comment mesurer si une stack d'IA d'ingénierie fonctionne réellement ?
Mesurez le temps de cycle, le taux de reprises, le temps d'intégration, le délai moyen de résolution et la fréquence des changements de contexte — pas seulement le nombre d'adoptions. Les ingénieurs seniors et les responsables d'équipe devraient suivre ces indicateurs par rapport à une référence. Si le temps de cycle diminue mais que les reprises augmentent, la stack produit du code plus vite sans les bons garde-fous. Si le temps d'intégration diminue et que les équipes continuent de livrer 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, et pas seulement une production plus rapide sur des 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 autorisations héritées et une synchronisation en temps réel entre les systèmes. La plupart des organisations commencent avec un workflow ou une équipe, puis étendent à partir de là.
