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

À qui s'adresse ce guide

Aux ingénieurs staff et principal, aux équipes plateforme et productivité développeur, ainsi qu'aux responsables engineering à qui l'on pose une question simple, mais dont la réponse ne l'est pas :

« Quelle est notre stratégie IA pour l'ingénierie logicielle, et quels outils doivent réellement faire partie de cette stack ? »

Ce guide a pour objectif de dresser un panorama de l'IA dans le développement logiciel. Il passe en revue les grandes catégories d'outils, les patterns qui émergent dans les équipes réelles, et les choix d'architecture qui distinguent les expérimentations à court terme des fondations durables. Il explique aussi où des plateformes comme Glean s'inscrivent dans ce paysage plus large.

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

Les équipes d'ingénierie logicielle sont sous pression pour :

• Livrer les fonctionnalités plus vite sur des marchés concurrentiels
• Préserver la fiabilité et la sécurité des systèmes à mesure que les architectures gagnent en complexité
• Faire plus avec des effectifs limités et des viviers de recrutement contraints

Le changement sous-jacent vient en grande partie de la dynamique « il nous faut une stratégie IA ». Il existe un enjeu concurrentiel, car les autres s'y mettent et avancent plus vite. Le sentiment général est qu'il ne faut pas se laisser distancer.

En parallèle, la manière 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 l'autocomplétion de code à la documentation en passant par les tests.
• Les développeurs constatent des gains de productivité significatifs avec des outils IA comme GitHub Copilot et des assistants similaires.
• L'IA accélère les tâches individuelles, mais le travail d'ingénierie reste tributaire de la mise en commun du contexte à travers les outils, les systèmes et les équipes.
• Il faut s'attendre à des plateformes IA ouvertes et composables : les ingénieurs veulent une couche de contexte et une base de gouvernance, mais aussi la liberté d'intégrer différents assistants de codage, modèles et workflows selon l'évolution des besoins.

La plupart des organisations se situent désormais 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 l'AI Transformation 100 estiment qu'environ 80 % des premières initiatives IA n'atteignent pas les gains de productivité imaginés, et une étude BCG de 2025 a relevé un ROI médian de seulement 10 % face à des objectifs de plus de 20 %  beaucoup de ces déploiements sont donc encore considérés comme des expérimentations plutôt que comme une infrastructure cœur de métier.
• D'autres en limitent l'usage en raison de préoccupations liées à la sécurité ou à la propriété intellectuelle.
  
  • Seuls 36 % des organisations avaient une politique IA en place, tandis que 45 % des salariés admettaient utiliser des outils IA interdits par leur employeur, ce qui rend la gouvernance fragile et pousse certains dirigeants à durcir les règles.
• 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 cite des recherches IDC indiquant que près de 90 % des données d'entreprise sont non structurées (emails, PDF, transcriptions d'appels, wikis, chats, tickets support, notes CRM)

C'est dans ce contexte qu'il faut évaluer les outils IA pour l'ingénierie : les équipes veulent des gains réels, pas seulement des pilotes, sans perdre le contrôle de leurs systèmes ni de leurs données.

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

La stack IA pour le développement logiciel n'est plus un simple choix de produit. C'est un portefeuille d'outils qui se répartissent généralement en quelques catégories.

2.1 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 inline, refactorings et génération de tests dans l'éditeur
• Création rapide de squelettes pour de nouveaux endpoints ou modules
• Débogage localisé dans un espace de travail ou un dépôt unique

Angles morts typiques

• Visibilité limitée sur les tickets, incidents ou justifications de conception
• Absence de vue unifiée à travers plusieurs repos, services et outils
• Modèles de sécurité et de gouvernance variables qui exigent une configuration soignée

Dans la pratique, de nombreuses équipes considèrent les assistants de codage comme des outils de puissance personnels pour les développeurs individuels, plutôt que comme la colonne vertébrale d'une stratégie IA d'entreprise.

2.2 Plateformes de contexte et de connaissance d'entreprise

Une deuxième catégorie se concentre sur la connexion 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 intégralité, et pas seulement des fichiers isolés, est essentiel pour transformer les sorties de l'IA en résultats réellement exploitables en entreprise. 

Ces plateformes :

• Unifient le code, les tickets, les logs, la documentation, les maquettes, les incidents et les discussions dans une couche de contexte unique, consciente des permissions.
• Aident les équipes à remonter d'une alerte ou d'une question jusqu'aux owners, aux travaux antérieurs et aux incidents passés.
• Proposent de la recherche, du Q& ;A et parfois des agents qui opèrent sur ce graphe élargi.

2.3 AIOps, observabilité et assistants d'incident

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

Les capacités courantes incluent :

• Le résumé des alertes, des traces et des logs
• La mise en évidence des régressions probables ou des composants impliqués dans un incident
• La fourniture d'étapes de runbook prêtes à l'emploi pour certains patterns

Ces outils peuvent être puissants dans leur périmètre, mais ils ont souvent un périmètre restreint : ils ne connaissent pas les workflows Jira, les conventions de ownership du code, ni les choix de conception consignés dans d'autres systèmes.

2.4 Plateformes IA généralistes et frameworks d'agents

Cela inclut :

• Les LLM hébergés
• Les frameworks de création d'agents et les outils d'orchestration
• Les builders 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 dépendent des données et de la structure que l'organisation leur fournit.

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

À travers ces catégories, un pattern d'architecture simple se dessine.

Couche 1 : contexte et connaissance d'entreprise

Cette couche répond à des questions comme :

• Comment nos services se relient-ils entre équipes et repos ?
• Quels incidents, tickets et documents de conception sont liés à ce changement ?
• Qui possède cette fonctionnalité ou ce système, et quelles contraintes ont été convenues ?

Elle comprend généralement :

• Connecteurs vers GitHub ou d'autres hébergeurs de code, Jira, outils d'incident, plateformes d'observabilité, wikis, espaces de stockage de documents, systèmes de chat, et plus encore
• Index lexicaux et sémantiques hybrides pour le code et les documents
• Un graphe d'entreprise reliant services, API, incidents, tickets, responsables et artefacts de conception

Couche 2 : surfaces de codage et d'interaction

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

• IDE et environnements de codage assistés par l'IA tels que Cursor et Claude Code
• GitHub et autres hébergeurs de code
• Jira et outils de suivi du travail
• Slack, Microsoft Teams et autres outils de collaboration

La plupart des organisations qui dépassent le stade des 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 s'appuient sur ce contexte plutôt que 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, les 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'examiner comment l'IA s'insère dans les workflows réels de développement logiciel.

4.1 Intégration et compréhension des services

La situation

• Les nouvelles recrues arrivent, les ingénieurs changent de projet et les responsabilités évoluent au fil du temps.
• Les connaissances importantes sont dispersées entre d'anciens documents de conception, tickets Jira, PR, incidents et fils Slack.

Comment les équipes utilisent l'IA

• Demander aux assistants d'expliquer des chemins de code ou des composants inconnus.
• Utiliser la recherche et le Q& ;A sur les documents internes et les tickets pour trouver le contexte pertinent.
• Déployer des agents capables de générer des synthèses d'intégration pour un service ou un projet.

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

• Une requête comme “Donne-moi une vue d'ensemble du service de paiements et lie les documents de conception clés” peut être résolue à travers le code, les tickets, les incidents et la responsabilité, et pas seulement via 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'intégration des développeurs prenait généralement moins d'un mois, contre 20 % des équipes n'utilisant pas l'IA.

4.2 Codage au 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 simples de bugs et refactorings itératifs.
• Les assistants de codage dans l'IDE accélèrent bien ce travail, mais peuvent passer à côté des contraintes de l'organisation.

Comment les équipes utilisent l'IA

• Autocomplétion inline et refactorings depuis des outils comme Cursor ou Copilot.
• Génération de tests et de mises à jour de la documentation en parallèle des changements.
• Combinaison de la recherche de code, d'agents de type Code Writer et des assistants de codage existants pour proposer des changements ciblés à partir de tickets ou de fils Slack.

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

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

4.3 Incidents et support de production

La situation

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

Comment les équipes utilisent l'IA

• Résumer les alertes et les logs dans leur contexte.
• Regrouper dans une vue unique les tickets associés, les changements de code et les incidents passés.
• Rédiger des postmortems et des communications client à partir de chronologies et d'artefacts réels.

Ici, la frontière entre les catégories devient claire :

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

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

À partir des échanges avec les responsables engineering et du marché au sens large, quelques questions d'évaluation reviennent systématiquement.

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

• Ne voit-il que le code dans l'espace de travail courant, ou peut-il voir les tickets, incidents et documents de conception pertinents ?
• Peut-il remonter d'une alerte dans Slack au code, aux responsables et aux incidents passés ?
• Comment gère-t-il les monorepos, les stacks polyglottes et plusieurs hébergeurs de code ?

5.2 Confiance et précision

• 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 d'échec sont-ils gérés, en particulier dans les workflows d'incident et de changement ?

5.3 Sécurité et gouvernance

• Où sont hébergés les index sémantiques et lexicaux pour le code et les documents ?
• Le code et les logs restent-ils dans 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 code writer ?

5.4 Adéquation avec les workflows existants

• L'outil s'intègre-t-il avec GitHub, Jira, l'observabilité et le chat, ou nécessite-t-il une interface séparée ?
• Peut-il fonctionner aux côtés des copilotes 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 à plusieurs équipes, sans bascule massive ?

Ces questions s'appliquent quel que soit l'outil en face de vous : assistant de codage, add-on d'observabilité ou plateforme de contexte d'entreprise.

6. Où Glean se situe dans ce paysage

Dans cette vue d'ensemble 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 designs, les incidents et les échanges dans une source unique de vérité pour le travail d'ingénierie.
• Donne aux équipes un seul endroit 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 vraies références et les responsabilités à travers les systèmes, au lieu de deviner à partir d'un seul dépôt ou espace de travail.

6.2 Plateforme ouverte et horizontale

• Fournit une plateforme agnostique aux 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, afin que vous n'ayez pas à reconstruire la plomberie pour chaque équipe ou assistant.
• Alimente des agents qui couvrent l'ingénierie, le support, 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 l'échelle en entreprise

• Propose un déploiement single tenant ou dans un VPC afin que le code, les logs et les données restent dans votre environnement.
• Applique de bout en bout les ACL des systèmes sources dans la recherche, Assistant et chaque agent, avec des journaux auditables pour les requêtes et les actions.
• Passe à l'échelle avec votre parc de connecteurs, de services et d'agents sans fragmenter les autorisations ni dupliquer les index.

6.4 Mieux ensemble 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 centrés sur l'édition et la complétion locales du code dans l'IDE.
• Glean fournit la couche de contexte gouvernée, à l'échelle de l'organisation, et l'expose via la recherche, Assistant, des agents et un serveur MCP que les assistants de codage peuvent appeler depuis l'éditeur.

Les schémas courants de « meilleure combinaison » incluent :

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

En ce sens, Glean fait partie du paysage de l'IA plutôt que de l'ensemble du paysage : il apporte aux équipes d'ingénierie une base de contexte et de sécurité stable sur laquelle plusieurs assistants et agents peuvent s'appuyer.

7. Tout mettre ensemble

À mesure que l'IA devient un standard en 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 vite que celles qui mènent des pilotes isolés dans des outils individuels.
• Les stacks les plus performantes combinent les outils plutôt que de parier sur un seul produit. Les assistants de codage, l'IA d'observabilité et les plateformes de contexte d'entreprise jouent chacun des rôles distincts.
• La sécurité, la gouvernance et l'explicabilité deviennent des prérequis. Exécuter les systèmes d'IA dans votre propre environnement, ancrer les réponses dans vos propres artefacts et préserver les autorisations existantes comptera autant que la qualité du modèle.

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

• Respecte la manière dont les ingénieurs travaillent réellement aujourd'hui
• Réduit la recherche de contexte au lieu d'ajouter des surfaces supplémentaires
• Laisse de la place à différents assistants de codage tout en consolidant les connaissances organisationnelles dans une couche unique et fiable

Glean est une façon 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 IA en évolution.