Rapport sur la stack d'outillage IA pour les ingénieurs logiciels

À qui s'adresse ce guide

Aux ingénieurs seniors et principaux, aux équipes plateforme et productivité des développeurs, ainsi qu'aux responsables de l'ingénierie à qui l'on pose une question simple appelant une réponse qui ne l'est pas :

« Quelle est notre stratégie IA pour l'ingénierie logicielle, et quels outils ont réellement leur place dans cette stack ? »

Ce guide se veut un panorama de l'IA dans le développement logiciel. Il passe en revue les grandes catégories d'outils, les tendances qui émergent au sein des équipes concrètes, et les choix architecturaux qui distinguent les expérimentations éphémères des fondations durables. Il explique aussi où se positionnent des plateformes comme Glean dans ce tableau d'ensemble.

1. Où en est l'ingénierie logicielle aujourd'hui

Les équipes d'ingénierie logicielle subissent la pression de :

• Livrer des fonctionnalités plus rapidement sur des marchés concurrentiels
• Maintenir des systèmes fiables et sécurisés à mesure que les architectures gagnent en complexité
• Faire plus avec des effectifs et des pipelines de recrutement limités

Le changement de fond provient en grande partie de l'injonction à « avoir une stratégie IA ». Il y a un enjeu concurrentiel, car d'autres s'y mettent et travaillent plus vite. Le sentiment général est de ne pas se laisser distancer.

Dans le même temps, la façon de travailler des ingénieurs évolue :

• L'IA générative et les grands modèles de langage font désormais partie des workflows quotidiens, de la complétion de code à la documentation et aux tests.
• Les développeurs font état de gains de productivité significatifs avec des outils d'IA tels que GitHub Copilot et des assistants similaires.
• L'IA accélère les tâches individuelles, mais le travail d'ingénierie dépend encore de la capacité à rassembler le contexte à travers les outils, les systèmes et les équipes.
• On peut s'attendre à des plateformes d'IA ouvertes et composables : les ingénieurs veulent une couche de contexte et une base de gouvernance, tout en gardant la liberté de brancher différents assistants de codage, modèles et workflows au fil de l'évolution des besoins.

La plupart des organisations se situent aujourd'hui quelque part entre l'expérimentation et la consolidation :

• Certaines équipes ont largement déployé des assistants de codage IA dans l'IDE.
  
  • …mais les dirigeants interrogés dans le cadre de l'AI Transformation 100 estiment qu'environ 80 % des premières initiatives IA n'atteignent pas les gains de productivité espérés, et une étude BCG de 2025 a révélé un ROI médian d'à peine 10 % contre des objectifs de plus de 20 % ; nombre de ces déploiements sont donc encore traités comme des expérimentations plutôt que comme une infrastructure cœur.
• D'autres limitent les usages en raison de préoccupations liées à la sécurité ou à la propriété intellectuelle.
  
  • Seules 36 % des organisations disposaient d'une quelconque politique IA, tandis que 45 % des collaborateurs ont admis utiliser des outils d'IA interdits par leur employeur, ce qui rend la gouvernance fragile et pousse certains dirigeants à durcir le ton.
• Beaucoup cherchent à comprendre comment l'IA doit interagir avec les systèmes existants comme GitHub, Jira, les outils d'observabilité et les wikis.
  
  • L'AI Transformation 100 renvoie à une étude IDC selon laquelle près de 90 % des données d'entreprise sont non structurées (e-mails, PDF, transcriptions d'appels, wikis, conversations, tickets de support, notes CRM)

Tel est le contexte dans lequel évaluer les outils d'IA pour l'ingénierie : les équipes veulent de véritables gains, pas seulement des pilotes, sans perdre le contrôle de leurs systèmes ou de leurs données.

2. Le paysage émergent des outils d'IA pour les ingénieurs

La stack d'IA pour le développement logiciel n'est plus un choix de produit unique. C'est un portefeuille d'outils qui tendent à se répartir en quelques catégories.

2.1 Les assistants de codage dans l'IDE

Exemples : Cursor, Claude Code, GitHub Copilot, Windsurf, Codeium, Sourcegraph Cody, et d'autres.

Ce qu'ils font bien

• Complétion de code en ligne, refactorisations et génération de tests dans l'éditeur
• Mise en place rapide de nouveaux endpoints ou modules
• Débogage localisé au sein d'un même espace de travail ou dépôt

Angles morts typiques

• Visibilité limitée sur les tickets, les incidents ou la justification de conception
• Absence d'une vue unifiée sur plusieurs dépôts, services et outils
• Modèles de sécurité et de gouvernance variables nécessitant une configuration soignée

En pratique, de nombreuses équipes considèrent les assistants de codage comme des outils de productivité personnels pour chaque développeur, plutôt que comme la colonne vertébrale d'une stratégie IA organisationnelle.

2.2 Les plateformes de contexte et de connaissance d'entreprise

Une deuxième catégorie se concentre sur la mise en relation des artefacts et des personnes derrière le code, plutôt que sur l'édition du code lui-même. Un système qui comprend l'organisation d'ingénierie dans son ensemble, et pas seulement les fichiers individuels, est essentiel pour transformer les sorties de l'IA en résultats exploitables en entreprise. 

Ces plateformes :

• Unifient code, tickets, logs, docs, designs, incidents et discussions au sein d'une couche de contexte unique, respectueuse des permissions.
• Aident les équipes à remonter d'une alerte ou d'une question jusqu'aux responsables, aux travaux antérieurs et aux incidents passés.
• Offrent de la recherche, des Q&R et parfois des agents opérant sur ce graphe plus large.

2.3 Les assistants AIOps, d'observabilité et d'incidents

Les outils de cette catégorie vivent généralement au sein des plateformes de monitoring et de réponse aux incidents. 

Leurs capacités courantes incluent :

• Le résumé des alertes, traces et logs
• La mise en évidence des régressions probables ou des composants impliqués dans un incident
• La fourniture d'étapes de runbook prédéfinies pour des schémas spécifiques

Ces outils peuvent être puissants au sein de leur substrat, mais ils ont souvent un périmètre restreint : ils ne connaissent pas les workflows Jira, les conventions de propriété du code, ni les décisions de conception consignées dans des systèmes distincts.

2.4 Les plateformes d'IA généralistes et les frameworks d'agents

Cela comprend :

• Les LLM hébergés
• Les frameworks de création d'agents et les outils d'orchestration
• Les créateurs d'IA low-code intégrés aux plateformes cloud ou SaaS

Ils facilitent le prototypage d'assistants ou d'agents, mais, à eux seuls, ils ne fournissent pas de graphe d'ingénierie d'entreprise. Ils reposent sur les données et la structure que l'organisation leur fournit.

3. Le modèle à deux couches : contexte vs surfaces de codage

À travers ces catégories, un schéma architectural simple se dessine.

Couche 1 : Contexte et connaissance d'entreprise

Cette couche répond à des questions telles que :

• Comment nos services s'articulent-ils entre les équipes et les dépôts ?
• Quels incidents, tickets et documents de conception sont liés à ce changement ?
• Qui est responsable de cette fonctionnalité ou de ce système, et quelles contraintes ont été convenues ?

Elle comprend généralement :

• Des connecteurs vers GitHub ou d'autres hôtes Git, Jira, des outils de gestion des incidents, des plateformes d'observabilité, des wikis, des espaces de stockage de documents, des systèmes de messagerie, et plus encore
• Des index hybrides lexicaux et sémantiques pour le code et les documents
• Un graphe d'entreprise reliant les services, les API, les incidents, les tickets, les responsables et les artefacts de conception

Couche 2 : surfaces de codage et d'interaction

C'est là que les ingénieurs travaillent réellement :

• Des IDE et des environnements de codage axés sur l'IA tels que Cursor et Claude Code
• GitHub et d'autres hôtes de code
• Jira et les outils de suivi des tâches
• Slack, Microsoft Teams et d'autres outils de collaboration

La plupart des organisations qui dépassent le stade des projets pilotes convergent vers un modèle à deux couches :

• Une couche de contexte qui comprend l'organisation et conserve les données dans ses limites de sécurité et de gouvernance.
• Plusieurs surfaces de codage et d'interaction qui puisent dans ce contexte au lieu de le réinventer chacune de leur côté.

Glean est conçu explicitement pour la couche de contexte, puis expose ce contexte dans les outils sur lesquels les ingénieurs s'appuient déjà via la recherche, Assistant, des agents et des protocoles comme MCP.

4. Comment les équipes utilisent réellement l'IA dans le SDLC

Plutôt que de raisonner en termes de fonctionnalités, il est utile d'observer comment l'IA se manifeste dans les véritables workflows de développement logiciel.

4.1 Onboarding et compréhension des services

La situation

• De nouveaux collaborateurs arrivent, les ingénieurs passent d'un projet à l'autre et la propriété évolue au fil du temps.
• Les connaissances importantes sont réparties entre d'anciens documents de conception, des tickets Jira, des PR, des incidents et des fils de discussion Slack.

Comment les équipes utilisent l'IA

• Demander aux assistants d'expliquer des chemins de code ou des composants peu familiers.
• Utiliser la recherche et les questions-réponses sur les documents et tickets internes pour trouver un contexte pertinent.
• Appliquer des agents capables de générer des résumés d'onboarding pour un service ou un projet.

Là où la couche de contexte existe, ces workflows deviennent plus fiables :

• Une requête comme « Donne-moi un aperçu du service de paiements et relie les principaux documents de conception » peut se résoudre à travers le code, les tickets, les incidents et la propriété, et pas seulement les commentaires de code.

GitLab a constaté que 43 % des équipes utilisant déjà l'IA pour le développement logiciel déclaraient que l'onboarding des développeurs prenait généralement moins d'un mois, contre 20 % des équipes n'utilisant pas l'IA.

4.2 Codage quotidien et petites modifications

La situation

• Les ingénieurs consacrent une grande partie de leur temps à de petites modifications incrémentales : mises à jour de configuration, corrections de bugs simples et refactorisations itératives.
• Les assistants de codage dans l'IDE sont efficaces pour accélérer ce travail, mais peuvent passer à côté des contraintes organisationnelles.

Comment les équipes utilisent l'IA

• La complétion en ligne et les refactorisations avec des outils comme Cursor ou Copilot.
• La génération de tests et de mises à jour de documentation en parallèle des modifications.
• La combinaison de la recherche de code, d'agents de type Code Writer et des assistants de codage existants pour proposer des modifications ciblées à partir de tickets ou de fils Slack.

Les équipes qui souhaitent un usage prêt pour la production commencent à :

• Définir des classes de modifications claires où l'IA est autorisée à proposer des changements.
• Utiliser les commentaires, les documents de conception et les tickets liés comme garde-fous, afin que les suggestions de l'IA reflètent de vraies contraintes plutôt que des modèles génériques.

4.3 Incidents et support en production

La situation

• Les ingénieurs d'astreinte jonglent entre les alertes, les tableaux de bord, les logs et les fils Slack tout en essayant d'identifier la cause racine et les responsables.
• Les changements de contexte sont nombreux et les connaissances historiques sur les incidents sont difficiles à réutiliser.

Comment les équipes utilisent l'IA

• Résumer les alertes et les logs en contexte.
• Rassembler les tickets, modifications de code et incidents passés associés dans une vue unique.
• Rédiger des post-mortems et des communications destinées aux clients à partir de chronologies et d'artefacts réels.

C'est ici que la frontière entre les catégories devient claire :

• Les outils d'observabilité fournissent des métriques et des traces.
• Les assistants de codage aident à proposer des correctifs au niveau du code.
• Une plateforme de contexte comme Glean relie le tout entre les systèmes et produit un récit cohérent.

5. Questions clés à poser lors de l'évaluation des outils d'IA

D'après les échanges avec des responsables de l'ingénierie et le marché au sens large, quelques questions d'évaluation reviennent sans cesse.

5.1 Couverture : que voit réellement l'outil ?

• Voit-il uniquement le code de l'espace de travail actuel, ou peut-il voir les tickets, incidents et documents de conception pertinents ?
• Peut-il remonter d'une alerte dans Slack jusqu'au code, aux responsables et aux incidents passés ?
• Comment gère-t-il les monorepos, les stacks polyglottes et les multiples hôtes de code ?

5.2 Confiance et exactitude

• L'outil ancre-t-il ses réponses dans votre propre code, vos tickets et vos logs, et peut-il montrer son raisonnement ?
• Les résultats sont-ils explicables et sourcés, ou nécessitent-ils une vérification manuelle à chaque fois ?
• Comment les modes de défaillance sont-ils gérés, en particulier dans les workflows d'incidents et de modifications ?

5.3 Sécurité et gouvernance

• Où sont hébergés les index sémantiques et lexicaux du code et des documents ?
• Le code et les logs restent-ils à l'intérieur de votre propre VPC, et existe-t-il des contrôles stricts de sortie pour les agents et la génération de code ?
• Existe-t-il des journaux d'audit clairs pour les requêtes et les actions, en particulier pour les workflows de type code writer ?

5.4 Adéquation avec les workflows existants

• L'outil s'intègre-t-il à GitHub, Jira, l'observabilité et la messagerie, ou nécessite-t-il une interface distincte ?
• Peut-il fonctionner aux côtés des copilotes d'IDE existants via des protocoles comme MCP, ou tente-t-il de les remplacer ?
• Quel est le parcours de déploiement d'une seule équipe vers plusieurs équipes sans bascule brutale ?

Ces questions s'appliquent, que l'outil devant vous soit un assistant de codage, un module complémentaire d'observabilité ou une plateforme de contexte d'entreprise.

6. La place de Glean dans ce paysage

Au sein de cet « état des lieux » plus large de l'IA dans l'ingénierie logicielle, Glean se situe dans la couche de contexte et de plateforme de la stack, et non dans la surface de l'IDE. Son rôle s'articule autour de trois thèmes.

6.1 Contexte d'entreprise approfondi

• Relie le code, les tickets, les logs, les documents, les conceptions, les incidents et les discussions en une source unique de vérité pour le travail d'ingénierie.
• Offre aux équipes un endroit unique pour répondre à des questions comme « qu'est-ce qui a changé, où, et qui en est responsable ? » sans avoir à assembler plusieurs outils.
• Permet aux assistants et aux agents de suivre de véritables références et la propriété entre les systèmes au lieu de deviner à partir d'un seul dépôt ou espace de travail.

6.2 Plateforme ouverte et horizontale

• Offre une plateforme agnostique vis-à-vis des modèles, capable de servir plusieurs départements, pas seulement l'ingénierie logicielle.
• Indexe les données une seule fois et les expose partout via des API et des outils compatibles MCP, pour que vous n'ayez pas à reconstruire la plomberie pour chaque équipe ou assistant.
• Alimente des agents qui couvrent l'ingénierie, l'assistance, les ventes, les opérations et d'autres fonctions, tout en partageant le même contexte d'entreprise gouverné.

6.3 Conçu pour la sécurité, la gouvernance et le passage à l'échelle en entreprise

• Propose un déploiement mono-locataire ou au sein d'un VPC, afin que le code, les journaux et les données restent dans votre environnement.
• Applique les ACL des systèmes sources de bout en bout dans la recherche, l'Assistant et chaque agent, avec des journaux auditables pour les requêtes et les actions.
• Évolue avec votre parc de connecteurs, de services et d'agents, sans fragmenter les permissions ni dupliquer les index.

6.4 Encore plus performant avec les assistants de codage

Glean n'est pas un assistant de codage comme Cursor ou Copilot. Il est conçu pour fonctionner à leurs côtés :

• Les assistants de codage restent concentrés sur l'édition et la complétion de code en local au sein de l'IDE.
• Glean fournit la couche de contexte gouvernée à l'échelle de l'organisation et l'expose via la recherche, l'Assistant, les agents et un serveur MCP que les assistants de codage peuvent appeler depuis l'éditeur.

Les schémas « encore plus performant ensemble » les plus courants incluent :

• Utiliser Cursor ou Claude Code dans l'éditeur tout en appelant Glean via MCP pour une recherche de code approfondie, le contexte des tickets et des incidents, et l'identification des propriétaires.
• Faire en sorte que les agents Glean transforment les bugs Jira ou les fils Slack en PR d'implémentation cadrées, que les développeurs affinent ensuite avec l'assistant de codage de leur choix.

En ce sens, Glean fait partie de l'écosystème de l'IA plutôt que de constituer l'écosystème tout entier : il offre aux équipes d'ingénierie une base stable de contexte et de sécurité sur laquelle plusieurs assistants et agents peuvent s'appuyer.

7. Assembler le tout

À mesure que l'IA devient la norme dans l'ingénierie logicielle, quelques tendances se confirment :

• L'IA passe de l'expérimentation à l'infrastructure. Les équipes qui standardisent une couche de contexte et des workflows clairs s'adapteront plus rapidement que celles qui mènent des projets pilotes isolés dans des outils individuels.
• Les stacks les plus performantes combinent plusieurs outils plutôt que de miser sur un produit unique. Les assistants de codage, l'IA d'observabilité et les plateformes de contexte d'entreprise jouent chacun un rôle distinct.
• La sécurité, la gouvernance et l'explicabilité deviennent des prérequis incontournables. Exécuter les systèmes d'IA dans votre propre environnement, ancrer les résultats dans vos propres artefacts et préserver les permissions existantes compteront autant que la qualité des modèles.

Pour les responsables de l'ingénierie, l'enjeu est de concevoir une stack d'IA qui :

• Respecte la façon dont les ingénieurs travaillent réellement aujourd'hui
• Réduit la chasse au contexte au lieu d'ajouter des surfaces supplémentaires
• Laisse la place à différents assistants de codage tout en consolidant les connaissances de l'organisation dans une seule couche de confiance

Glean est l'un des moyens de mettre en œuvre cette couche de contexte pour les équipes d'ingénierie logicielle, aux côtés des nombreux autres outils de l'écosystème d'IA en pleine évolution.