L’IA générative pour les ingénieurs logiciel ne se limite pas à compléter du code. La prochaine vague de gains de productivité viendra de l’aide apportée aux ingénieurs pour trouver le contexte, gérer les incidents et livrer en toute sécurité au sein des systèmes où le code vit réellement.
GitHub Copilot écrit déjà près de la moitié du code d’un développeur moyen — pourtant, une étude contrôlée récente a montré que des développeurs expérimentés utilisant des outils d’IA mettaient 19% plus de temps à terminer leurs tâches, même s’ils pensaient que l’IA les avait accélérés de 20%.
Le goulot d’étranglement n’est plus la saisie. C’est le système de contexte autour du code, et la plupart des stacks d’ingénierie n’ont pas construit la couche qui l’alimente.
En un coup d’œil
- Les assistants de codage IA ont résolu un problème que les ingénieurs n’ont plus vraiment. Le vrai frein, c’est la reconstruction du contexte à travers GitHub, Jira, Slack, les outils d’observabilité, les docs de design et les wikis.
- Une stack IA à deux couches — surfaces de codage au-dessus, couche de contexte partagée en dessous — devient le modèle d’architecture qui distingue les équipes obtenant un vrai ROI de celles qui mènent des pilotes déconnectés.
- La confiance, la gouvernance et l’explicabilité comptent désormais autant que la qualité du modèle. 45% du code généré par l’IA contient au moins une vulnérabilité de haute criticité.
- Les équipes qui obtiennent des gains mesurables grâce à l’IA en ingénierie — notamment LinkedIn, Uber, et deux des trois plus grandes organisations utilisatrices d’assistants de codage — standardisent une couche de contexte partagée que chaque outil peut interroger.
- Les responsables engineering qui évaluent des outils d’IA devraient poser quatre questions : De quel contexte dispose-t-il ? Comment la confiance est-elle gagnée ? Où vont les données ? Est-ce compatible avec la façon dont les équipes travaillent déjà ?
Le paradoxe de productivité de l’IA en ingénierie
Trois écarts reviennent sans cesse dans les échanges avec les responsables engineering, et ensemble ils expliquent pourquoi l’IA dans le SDLC donne l’impression qu’elle devrait mieux fonctionner qu’elle ne le fait.
L’écart de résultats. Dans un essai contrôlé randomisé mené auprès de développeurs open source expérimentés, les issues pour lesquelles les développeurs étaient autorisés à utiliser des outils d’IA ont pris 19% plus de temps à être résolues. Les développeurs s’attendaient à aller 24% plus vite au départ.
Après coup, ils pensaient que l’IA les avait accélérés d’environ 20%. L’assistant propose en permanence du code, donc le travail paraît plus rapide — mais avec un contexte limité au fichier ou au repo, il manque souvent des contraintes issues des tickets, des designs et d’autres services. Le temps de saisie gagné revient plus tard sous forme de retouches et d’intégration.
L’écart de confiance. Avec le temps, cette illusion de productivité crée un problème de confiance. Plus de développeurs doutent activement de la précision des outils d’IA qu’ils ne leur font confiance — environ 46% contre 33%. 66% disent que leur plus grande frustration vient de solutions IA « presque justes, mais pas tout à fait ». 45% indiquent que déboguer du code généré par l’IA prend souvent plus de temps que de l’écrire eux-mêmes. Quand l’assistant a un contexte limité, il produit un code plausible mais qui ne correspond pas parfaitement au système environnant, et les ingénieurs passent le temps économisé à traquer l’écart.
L’écart de sécurité. Les revues de sécurité mettent en évidence de vrais risques. Dans certaines analyses, près de 45% du code généré par l’IA contenait au moins une vulnérabilité de haute criticité, dont des XSS ou des injections SQL.
Sans garde-fous solides, contexte réel et schémas de revue clairs, l’IA peut augmenter discrètement votre surface d’attaque tout en aidant à livrer plus vite des fonctionnalités. Le problème n’est pas l’IA dans le SDLC. Le problème, c’est que la couche autour de l’IA compte autant que l’IA elle-même.
Le schéma commun à ces trois écarts est le même. Les assistants de codage excellent sur la partie du métier déjà automatisée dans le cerveau de tout le monde. Ils sont moins utiles sur la partie qui exige de comprendre le reste du système — ce qui représente l’essentiel du travail.
Pourquoi le goulot d’étranglement est passé de la création de code à l’assemblage du contexte
Pendant des décennies, le facteur limitant pour livrer du logiciel était la vitesse à laquelle un ingénieur pouvait transformer une intention en code. Cette équation a changé.
Dans de nombreuses organisations — surtout celles nativement orientées IA — les ingénieurs seniors ont cessé d’écrire du code ligne par ligne. Ils définissent l’intention, fixent des contraintes et relisent les diffs pendant que les systèmes prennent en charge une grande partie du travail mécanique.
Le vrai goulot d’étranglement n’est plus la vitesse à laquelle quelqu’un peut produire du code. C’est la vitesse à laquelle il peut assembler le bon contexte, les bons garde-fous et les bons workflows autour de ce code pour qu’il soit correct, sûr et aligné avec la bonne architecture.
Regardez où passe réellement le temps d’un ingénieur au cours d’une journée type.
Ouvrir un ticket Jira. Passer au doc de design lié dans le ticket.
Passer au fil Slack où les compromis ont été discutés.
Passer au runbook du service.
Passer à un postmortem d’incident passé.
Passer à GitHub pour trouver la dernière personne ayant touché ce chemin de code.
Revenir dans l’IDE pour écrire la modification. Puis revenir au fil de revue de PR lorsque la modification atterrit.
L’IDE n’est qu’un onglet dans une chaîne de cinq ou six. L’assistant de codage vit dans cet onglet-là. Il ne voit pas le reste de la chaîne. Lorsqu’il génère une suggestion de code, il raisonne sur le fichier devant lui — pas sur le ticket qui explique pourquoi la modification existe, la décision de design qui a écarté trois autres approches, ni l’incident du trimestre dernier qui explique un commentaire critique dans le code legacy.
Ce manque apparaît dans les données. 62% des développeurs disent que reconstruire le contexte à travers plusieurs outils les ralentit. 41% identifient des informations obsolètes, incohérentes ou cloisonnées comme leur plus grand drain de productivité. 44% des organisations rapportent que l’onboarding de nouveaux développeurs prend plus de deux mois, et ce temps est presque entièrement consacré à l’assemblage du contexte — trouver les bonnes docs, les bonnes personnes, les bonnes décisions passées.
L’IA n’a pas supprimé ce travail. Dans de nombreux cas, elle l’a rendu plus visible en supprimant le temps de saisie qui le masquait auparavant. Résultat : la friction, pas les fonctionnalités, est le vrai frein.
Le modèle à deux couches : surfaces de codage et surfaces de contexte
Si vous observez les outils d’IA dans la stack d’ingénierie moderne, un schéma se dessine.
Un premier ensemble d’outils correspond à l’endroit où les ingénieurs font le travail. IDE, hébergeurs de code, Jira, chat, environnements de développement augmentés par l’IA comme Cursor ou Claude Code. Ce sont les surfaces où l’intention se transforme en modifications.
Un autre ensemble se concentre sur la compréhension du travail. Ils agrègent code, tickets, incidents, docs, logs et personnes en une vue cohérente. Ils répondent à des questions comme : comment nos services sont-ils liés entre équipes et repos ? Quels incidents, tickets et docs de conception sont associés à ce changement ? Qui est propriétaire de ce système aujourd’hui, et quelles contraintes avons-nous actées ?
Pour beaucoup d’équipes, cette division du travail conduit à la formation d’un modèle à deux couches : une surface de code au-dessus, une surface de contexte en dessous.
La couche de contexte se connecte aux principaux systèmes
GitHub ou GitLab et autres hébergeurs, Jira, outils de gestion d’incidents, plateformes d’observabilité, wikis, espaces de stockage de documents, Slack ou Teams, et plus encore. Elle indexe le code et les documents avec une recherche hybride — lexicale et sémantique — pour comprendre votre stack, vos conventions de nommage et votre jargon.
Elle construit un graphe d’entreprise reliant services, API, incidents, tickets, propriétaires et artefacts de conception, au lieu de traiter l’ensemble comme du texte à plat. Et elle respecte les limites de sécurité et de gouvernance de bout en bout : ACL des systèmes sources, résidence des données, auditabilité.
La couche de code est celle où les ingénieurs passent l’essentiel de leur temps au quotidien.
IDE et environnements de code centrés sur l’IA, GitHub et autres hébergeurs de code, Jira et le suivi du travail, Slack et Teams. Ces surfaces offrent des capacités puissantes et de l’automatisation, mais elles ne peuvent pas s’appuyer sur le contexte d’entreprise existant si ce contexte doit être réinjecté et réinventé à chaque requête.
Les plateformes conçues pour la couche de contexte — comme Glean — se connectent aux principaux systèmes d’ingénierie et exposent un graphe d’entreprise tenant compte des permissions, sur lequel d’autres outils d’IA peuvent s’appuyer. Deux des trois plus grandes organisations d’assistants de code s’appuient sur Glean pour alimenter la couche de contexte derrière leurs outils d’ingénierie.
Pourquoi cette séparation compte : les surfaces de code excellent dans la génération et l’édition locales, mais elles sont construites autour du fichier ou du repo. Une couche de contexte dédiée permet aux équipes de conserver les éditeurs auxquels elles font déjà confiance, tout en gagnant la compréhension transverse entre systèmes qui leur manque.
Vous indexez une seule fois. Vous réutilisez ce contexte dans les outils et surfaces.
Vous voulez le framework complet ? Le guide pratique Glean sur la stack IA présente le modèle à deux couches, la grille d’évaluation en quatre questions, et les cinq priorités pour les responsables engineering qui déploient l’IA dans le SDLC.
Lire le guide pratique →
Comment le modèle à deux couches se concrétise : onboarding, développement au quotidien et incidents
Le modèle à deux couches n’est pas un cadre abstrait. Il transforme trois workflows qui occupent la majeure partie du temps des ingénieurs.
Onboarding et compréhension des services.
La propriété change en permanence. Des nouvelles recrues arrivent, les équipes se réorganisent, les services survivent à leurs auteurs d’origine. Les informations dont un nouvel ingénieur a besoin pour monter en compétence sont généralement dispersées entre d’anciens docs de conception et ADR, des tickets et epics Jira, des PR et revues de code, des rapports d’incident et runbooks, des fils Slack et des chaînes d’e-mails.
Près de la moitié des organisations disent que l’onboarding prend plus de deux mois. Quand les développeurs utilisent des outils d’IA avec une véritable couche de contexte en dessous, 43% disent que le temps d’onboarding tombe à moins d’un mois.
Avec Glean Search et Glean Chat reposant sur l’Enterprise Graph, un nouvel ingénieur peut demander « donne-moi une vue d’ensemble du service de paiements et lie les principaux docs de conception » et obtenir une réponse construite à partir du code, des tickets, des incidents et des informations de propriété — pas seulement à partir de ce qui correspond au mot-clé « payments » dans des commentaires de code.
Développement au quotidien et changements de routine.
Une grande partie du temps d’ingénierie s’évapore dans du travail de routine : ajustements de config, petites corrections de bugs, refactorings incrémentaux qui maintiennent les systèmes en bonne santé mais détournent l’attention des projets plus importants. Les assistants de code dans l’IDE sont déjà très performants sur ce terrain.
Associés à la recherche de code et à des agents de rédaction de code, ils peuvent même proposer des changements ciblés directement à partir d’un ticket Jira ou d’un fil Slack, au lieu de partir d’un éditeur vide. Les équipes qui obtiennent des résultats prêts pour la production vont un cran plus loin : elles définissent des classes de changements claires où l’IA est autorisée à proposer des modifications — changements de niveau de logs, certaines mises à jour de configuration, refactorings non fonctionnels, documentation et tests — et elles considèrent les commentaires, les documents de conception et les tickets liés de la couche de contexte comme des garde-fous.
Les suggestions s’alignent sur les exigences et contraintes réelles, et pas seulement sur des schémas génériques déjà vus par le modèle.
Incidents et support production.
Pendant un incident, les ingénieurs jonglent entre alertes, tableaux de bord, logs, runbooks, Jira et Slack, tout en essayant de répondre à trois questions de base : qu’est-ce qui a changé, qu’est-ce qui est cassé, et qui doit être impliqué. À elle seule, l’alternance constante entre outils ralentit tout.
79% des équipes d’ingénierie explorent déjà l’IA pour des tâches de suivi des incidents. Avec une plateforme de contexte en dessous, Glean Agents peut résumer alertes, traces et logs en un récit cohérent, rassembler les tickets associés, les changements de code récents, les incidents passés et les responsables dans une vue unique, et rédiger des premières versions de chronologies, postmortems et mises à jour client à partir d’événements et d’artefacts réels.
La séparation entre les deux couches est la plus facile à voir ici. Les outils d’observabilité fournissent les signaux bruts — métriques, traces, logs. Les assistants de code aident à proposer et à appliquer des corrections au niveau du code une fois que vous savez ce qui ne va pas. La couche de contexte relie les informations entre systèmes pour que l’assistant ne devine pas à partir des données d’un seul outil.
Dans ces trois workflows, l’assistant de code compte. Et il compte encore plus lorsqu’il s’appuie sur une couche qui connaît déjà le reste du système.
Quatre questions à se poser avant d’ajouter un nouvel outil d’IA
Pour passer de l’expérimentation à quelque chose que vous pouvez standardiser, il est utile d’avoir un socle commun de questions d’évaluation. Elles reviennent souvent dans les échanges avec les leaders d’ingénierie.
1. De quel contexte dispose-t-il réellement ?
La plupart des outils prétendent être « context-aware ». La vraie question est : du contexte sur quoi ?
Ne voit-il que le repo ou le buffer courant, ou peut-il aussi voir les tickets associés, les incidents, les documents de conception et les runbooks ?
Peut-il suivre une chaîne du type alerte Slack → ticket d’incident → changements de code pertinents → responsables → incidents passés, ou faut-il encore assembler tout ça à la main ?
Comment se comporte-t-il avec des monorepos, plusieurs hébergeurs de code et des stacks polyglottes — a-t-il été testé à cette échelle, ou est-ce du « future work » ?
Si l’outil ne peut pas voir le même graphe que celui sur lequel vos ingénieurs raisonnent, il donnera des réponses superficielles ou trompeuses.
2. Comment la confiance est-elle gagnée, et non supposée ?
Les ingénieurs ne feront pas confiance à un système qui se comporte comme une boîte noire, quel que soit le niveau de polish de l’UI. Les réponses sont-elles ancrées dans vos propres artefacts — code, tickets, logs — avec des liens permettant d’inspecter la source ?
Les résultats sont-ils sourcés et explicables, ou ressemblent-ils à un mur de texte qu’il faut revalider manuellement ?
Que se passe-t-il en cas de mauvaise entrée ou de cas limites dans les workflows d’incident et de changements — est-ce que ça échoue de manière sûre et visible, ou est-ce que ça hallucine discrètement ?
Si les équipes doivent refaire le travail pour le vérifier, vous n’obtiendrez pas une adoption réelle.
3. Où vont vos données, et qui peut agir dessus ?
Dès que l’IA peut lire le code, les logs et les tickets — et surtout dès qu’elle peut agir — vous prenez une décision de sécurité et de gouvernance, pas seulement une décision d’outillage.
Où sont hébergés les index du code et des documents : dans votre tenant, dans le multi-tenant du fournisseur, ailleurs ?
Le code et les logs restent-ils dans votre VPC ou votre compte cloud, et y a-t-il des contrôles d’egress stricts sur ce que les agents et les outils de génération de code peuvent envoyer à des modèles externes ?
Toutes les requêtes et actions sont-elles journalisées d’une façon exploitable par votre équipe sécurité pour l’audit et la réponse aux incidents ? Si vous ne pouvez pas répondre clairement à ces questions, votre équipe sécurité bloquera — ou devrait le faire.
4. Est-ce compatible avec la façon dont vos équipes travaillent déjà ?
Les meilleurs outils disparaissent dans les workflows existants. Les pires demandent aux ingénieurs de vivre dans un nouvel onglet. S’intègre-t-il proprement à GitHub ou GitLab, Jira, votre stack d’observabilité et Slack ou Teams, ou est-ce une interface déconnectée de plus ?
Peut-il coexister avec des copilots dans l’IDE — via MCP ou équivalent — en les utilisant pour l’édition tandis qu’il fournit la couche de contexte partagée ?
Ou vous oblige-t-il à tout remplacer ? Le serveur MCP de Glean est conçu pour ce modèle de coexistence : Cursor, GitHub Copilot et Claude Code peuvent s’appuyer sur la même couche de contexte gouvernée sans que les ingénieurs quittent leur éditeur. Si la réponse à « où les ingénieurs utiliseraient-ils cela au quotidien ? » n’est pas claire, l’outil restera un pilote, et ne fera pas partie de votre SDLC.
Ces quatre questions s’appliquent aux assistants de code, aux modules d’observabilité, aux frameworks d’agents et aux plateformes de contexte. Elles permettent de vérifier si un outil va réellement améliorer la façon dont vos systèmes sont construits et opérés — ou simplement ajouter une couche de complexité supplémentaire.
La prochaine course n’est pas d’avoir plus de copilots. C’est la couche en dessous.
Dans la plupart des organisations, il y a un an, la discussion était : « est-ce qu’on a de l’IA dans l’IDE ? » Dans la plupart des cas, la réponse est oui — plusieurs fois. Cursor, GitHub Copilot, Claude Code et d’autres sont désormais la base. La nouvelle discussion est différente. C’est : « est-ce que le reste du système soutient ce que ces outils font ? »
Pour les équipes qui obtiennent un ROI réel, la réponse converge vers une couche de contexte partagée, sous les surfaces de développement. Glean est conçu pour cette couche. Il unifie le code, les tickets, les logs, les documents, les incidents et les discussions issus d’outils comme GitHub, GitLab, Jira, des plateformes d’observabilité, des wikis, des espaces de stockage de documents, et Slack ou Teams, au sein d’un Enterprise Graph unique, à jour et respectueux des permissions.
Ce graphe est accessible depuis l’éditeur — via la recherche, Glean Chat, Glean Agents et des outils compatibles MCP — afin que les assistants de code puissent s’appuyer sur la même source de vérité approuvée par vos équipes sécurité et plateforme. Les résultats clients confirment ce modèle. LinkedIn économise 2,4 M$ par an grâce à un agent Threat-bot propulsé par Glean. Les équipes Uber livrent du code 20% plus vite après avoir déployé Glean sous leurs workflows d’ingénierie.
Un exemple concret :
Un grand distributeur spécialisé dans l’amélioration de l’habitat a mesuré une hausse de 5,3 % de la productivité des développeurs. Un seul agent déployé au sein de l’équipe d’ingénierie de Glean a permis de récupérer plus de 17 000 heures d’ingénierie par an et plus de 1,7 M$ de ROI. Ce ne sont pas des chiffres de phase pilote. C’est ce qui se passe quand l’IA est intégrée à une base de contexte et de sécurité stable, plutôt que greffée à des outils pris individuellement.
La répartition des rôles devient simple. Les assistants de code restent concentrés sur l’édition locale et la génération dans l’IDE. La couche de contexte apporte une vue gouvernée, à l’échelle de l’organisation, de l’environnement d’ingénierie, accessible depuis l’éditeur quand on en a besoin.
En pratique, cela ressemble à un Glean Agent qui transforme un bug Jira ou un fil Slack en une PR d’implémentation cadrée, que les développeurs affinent et prolongent avec leur assistant de code préféré. Ou à la résolution d’un incident en production dans Cursor ou Claude Code, l’assistant appelant Glean via MCP pour intégrer les incidents récents, les tickets Jira, les responsables et les docs de conception, puis proposer un correctif conscient du contexte, sans quitter l’éditeur.
C’est ce qui fait que l’IA ressemble à une brique de la stack plutôt qu’à un module annexe : une base de contexte et de sécurité stable sur laquelle plusieurs assistants et agents peuvent s’appuyer, tout en laissant aux développeurs la liberté de conserver les outils auxquels ils font déjà confiance.
Pour les responsables engineering qui veulent prendre de l’avance, cinq priorités méritent d’être au cœur de la mise en œuvre de l’IA.
- Commencez à mesurer l’impact en termes de temps de cycle et de qualité, pas seulement en fonction du nombre de développeurs qui ont installé un assistant de code.
- Concentrez les investissements IA sur la réduction des handoffs et des reprises entre systèmes, pas uniquement sur une génération de code plus rapide dans un outil unique.
- Faites de la sécurité, de la gouvernance et de la transparence une priorité avant la mise en œuvre et l’adoption. La confiance et la sûreté sont des prérequis à l’IA, pas une réflexion tardive à « patcher » ensuite.
- La prolifération des SaaS est arrivée en premier. La prolifération de l’IA viendra en second. Gardez l’évolutivité à l’esprit lorsque vous cherchez des solutions. Privilégiez des plateformes ouvertes qui vous permettent d’appliquer le contexte, de conserver la visibilité et de faire respecter les politiques sur l’ensemble de vos outils IA actuels et futurs.
- Reliez un contexte plus large — et votre organisation dans son ensemble — au travail que vous réalisez. Réunir les bonnes données est la clé d’une meilleure création de code. Trouvez des systèmes de contexte adaptés à votre SDLC et à votre stack.
La course n’est plus « à quelle vitesse pouvons-nous ajouter un nouvel outil IA ? ». C’est « pouvons-nous concevoir une stack IA qui correspond à la façon dont nos ingénieurs travaillent réellement, qui nous garde aux commandes de nos systèmes et de nos données, et qui donne à chaque outil la même vision fiable de notre environnement ? »
{{richtext-banner-component}}
Questions fréquentes
Quel est le principal frein à la productivité des ingénieurs logiciels qui utilisent des outils d’IA ?
Le principal frein n’est pas une génération de code lente — c’est la reconstruction du contexte à travers de multiples outils. 62 % des développeurs citent cela comme un ralentissement majeur, et 41 % pointent des informations obsolètes, incohérentes ou cloisonnées comme leur premier frein à la productivité. Les assistants de code ne comblent pas ce manque, car ils ne voient que le fichier ou le repo devant eux.
Pourquoi les développeurs sont-ils plus lents avec des assistants de code IA dans certaines études ?
Dans un essai contrôlé, des développeurs expérimentés utilisant des outils IA étaient 19 % plus lents sur des tâches qu’ils s’attendaient à terminer 24 % plus vite. L’assistant suggère du code en continu, donc le travail paraît plus rapide, mais les suggestions passent souvent à côté de contraintes issues des tickets, des conceptions et d’autres services. Le temps gagné à taper revient ensuite sous forme de reprises et d’efforts d’intégration.
Qu’est-ce que la stack IA à deux couches pour l’ingénierie logicielle ?
Le modèle à deux couches sépare la stack IA d’ingénierie en surfaces de codage — IDE, hébergeurs de code, Jira, chat et environnements de codage IA — et une couche de contexte sous-jacente qui connecte code, tickets, incidents, docs, logs et personnes dans un graphe unique tenant compte des autorisations. La couche de codage gère la génération locale. La couche de contexte gère la compréhension inter-systèmes.
Comment Glean s’intègre-t-il avec des outils comme GitHub Copilot, Cursor et Claude Code ?
Glean est conçu pour fonctionner aux côtés des assistants de code que les ingénieurs utilisent déjà, pas pour les remplacer. Les assistants de code restent concentrés sur l’édition locale et la génération dans l’IDE. Glean fournit la couche de contexte gouvernée, à l’échelle de l’organisation — accessible depuis l’éditeur via la recherche, Glean Chat, Glean Agents et un serveur MCP — afin que les assistants puissent intégrer tickets, incidents, responsables et docs de conception sans quitter l’IDE.
