Et si le vrai problème venait du codage par IA

Le codage assisté par l’IA accélère le développement mais risque de compromettre la fiabilité du code

L’IA écrit plus de code que jamais. Chez Microsoft, elle génère déjà 30 % de la base de code de l’entreprise. Chez Google, elle représentait environ 25 % en 2024. Parmi les startups, la courbe d’adoption est encore plus raide. Y Combinator a noté que dans son lot de l’hiver 2025, un quart des entreprises avaient 95% de leur code écrit par l’IA.

La vitesse de développement a augmenté. C’est une bonne chose. Mais soyons clairs : plus de code ne signifie pas toujours un meilleur code. La vitesse sans le contrôle est coûteuse. Les LLM (grands modèles de langage) génèrent un code fonctionnel, mais loin d’être à toute épreuve.fonctionnel, mais loin d’être à l’épreuve des balles. Il est souvent verbeux et gonflé. Cela augmente la taille des lots, c’est-à-dire le volume global de code introduit dans le système à la fois. Des lots plus importants signifient plus de risques par version. Le débogage devient plus difficile. Et les taux d’échec augmentent lorsque les systèmes ne sont pas conçus pour s’adapter.

Les pipelines de test, les tests unitaires, les tests d’intégration, l’analyse statique, tous essaient de détecter les erreurs. La plupart des équipes font confiance à leur CI/CD pour jouer le rôle de gardien. Mais ce n’est pas suffisant. La couverture complète des tests est rare. Il y a toujours des fuites de complexité. Et certains problèmes ne font surface que sous la pression, pas dans le cadre de l’assurance qualité.

L’IA modifie la façon dont les développeurs interagissent avec le code. Au lieu d’appliquer leurs connaissances approfondies du domaine pour écrire des systèmes propres et faciles à maintenir, ils examinent et approuvent des suggestions générées par des machines. C’est rapide et efficace, mais cela masque une baisse de la familiarité avec la base de code. Au fil du temps, vos meilleurs ingénieurs cessent d’être des experts en systèmes. Cela coûte cher.

L’idée est simple : l’utilisation de l’IA pour accélérer la production n’est rentable que si le système qui l’entoure, l’automatisation des mises en production, la surveillance et le suivi des incidents, suit le mouvement. Sinon, tout ce que vous faites, c’est générer des problèmes plus rapidement que vous ne pouvez les diagnostiquer.

La dépendance à l’égard du code généré par l’IA érode l’expertise des développeurs et met à rude épreuve les équipes SRE.

Parlons des ingénieurs débutants. Ils arrivent dans les équipes non pas pour apprendre les principes fondamentaux du code, mais pour approuver les demandes d’extraction suggérées par l’IA. Cela signifie qu’ils ont moins d’occasions de développer des compétences essentielles, comme la manière de réfléchir à un problème, de calibrer les décisions ou d’optimiser la fiabilité. Ce qui est perdu, ce n’est pas seulement la profondeur technique, c’est la compétence à long terme.

Les développeurs seniors ne sont pas épargnés. Au fur et à mesure qu’ils délèguent une plus grande partie de leur réflexion à la machine, ils commencent à désapprendre les connaissances qui les rendaient efficaces. L’expertise du domaine s’estompe. La connaissance du système s’amenuise. Vous vous retrouvez avec des équipes qui peuvent approuver des changements, mais qui ont du mal à expliquer pourquoi ces changements sont importants, ou comment les annuler lorsque quelque chose ne fonctionne pas.

Pour les équipes d’ingénierie de la fiabilité des sites (SRE), c’est là que les choses se compliquent. Vous avez plus de déploiements, plus d’incidents et moins de personnes qui connaissent vraiment le système. Et les entreprises ne prévoient pas nécessairement d’embaucher davantage d’intervenants. Au contraire, elles réduisent les coûts et attendent de l’IA qu’elle comble cette lacune.

Mais voici le problème : L’IA n’étudie pas les problèmes de production avec l’expérience. Elle ne comprend pas les décisions architecturales historiques ou les cas limites bizarres que les utilisateurs ont découverts il y a trois versions. Vous avez besoin d’humains pour cela. Vous avez besoin d’individus qui connaissent le contexte. L’IA peut faire remonter des logs et faire des recommandations, bien sûr. Mais si votre équipe est à bout de souffle et que les connaissances approfondies ont disparu, les délais de résolution augmentent. La fiabilité en pâtit.

La meilleure solution consiste à combiner les capacités de l’IA avec des actions délibérées pour préserver l’expertise. Promouvoir l’apprentissage en profondeur des systèmes. Laissez l’IA gérer l’échelle, pas la stratégie. Utilisez-la pour accélérer, pas pour remplacer.

Les outils de gestion des incidents pilotés par l’IA peuvent renforcer les capacités SRE.

L’IA ne se contente pas d’écrire du code, elle commence aussi à aider à le nettoyer. L’essor des outils SRE d’IA est une réponse rationnelle à la complexité créée par le développement généré par l’IA. Ces outils ne remplacent pas les ingénieurs, ils les complètent. Ils peuvent traiter des données, des journaux, des mesures, des traces, des différences de code et des problèmes de surface en grand volume et à grande vitesse plus rapidement qu’un humain. Cette précision, sous pression, est importante.

Les plateformes modernes de gestion des incidents utilisent déjà de grands modèles de langage pour trier les conversations internes d’une entreprise, Slack, les transcriptions de Zoom, les fils de discussion, afin de fournir des résumés rapides. Cela permet aux intervenants de gagner du temps. Cela permet également aux dirigeants d’obtenir des mises à jour claires et concises sans perdre de temps à rédiger des rapports manuels. Mais ce n’est qu’un début.

Une nouvelle classe d’IA SRE est en train d’émerger. Ces systèmes peuvent enquêter sur les alertes, évaluer les effets en aval et suggérer des solutions. Tout cela en donnant des notes de confiance, afin que les équipes sachent dans quelle mesure elles peuvent se fier au jugement de l’outil. Au début, ces outils devraient fonctionner en mode lecture seule. Cela donne à votre équipe le temps de valider les suggestions tout en gardant les garde-fous intacts.

En fin de compte, après avoir obtenu de bons résultats, vous pouvez augmenter les responsabilités. Mais ne vous y trompez pas, vous devez suivre le même chemin de gouvernance que celui que vous appliquez aux changements induits par l’homme. Incluez des revues de code. Laissez les déploiements canaris détecter les problèmes de bord. Et consignez toujours ce que l’IA a fait et pourquoi elle a recommandé une action spécifique.

Pour les dirigeants de niveau C, il s’agit d’une opportunité à saisir. Ces outils sont de puissantes couches d’intelligence supplémentaires. S’ils sont déployés de manière réfléchie, ils augmentent la productivité de votre équipe sans sacrifier la fiabilité. Mais si vous abandonnez la surveillance, vous n’augmentez pas seulement le risque, vous perdez le contrôle. Gardez les pieds sur terre. Procédez à des audits fréquents. Développez vos capacités, pas votre fragilité.

Les outils d’IA SRE introduisent des risques importants en matière de sécurité, de coûts et de dépendance.

Donner à une IA l’accès à votre pile de surveillance, à vos journaux, à votre base de code, ce n’est pas de la confiance zéro. C’est un accès total. Cela signifie que les risques liés à la confidentialité des données, au stockage, à la conformité et à la propriété intellectuelle passent directement en tête de liste. Vous ne pouvez pas vous permettre d’être désinvolte quant à ce que l’IA voit, à l’endroit où ces données sont stockées ou à la manière dont les fournisseurs s’entraînent sur ces données.

Certains signaux du monde réel renforcent déjà cet avertissement. Samsung aurait eu des fuites de données internes sensibles suite à l’utilisation de modèles d’IA tiers. Il est difficile de se remettre d’une telle violation, tant sur le plan technique que stratégique. L’attente est donc simple : contrôlez vos données. Si votre fournisseur ne peut pas expliquer comment son système forme, stocke et isole les données de l’entreprise, c’est qu’il n’est pas prêt.

Le coût mérite également d’être examiné de près. Les plateformes d’IA générative facturent souvent par nombre de jetons : plus votre système traite d’entrées et de sorties, plus vos frais mensuels augmentent. Ce modèle ne s’arrête pas automatiquement. Si vous utilisez l’analyse d’incidents par l’IA pour des alertes insignifiantes, ou si l’outil ne parvient pas à fournir des informations après plusieurs tentatives, vous dépensez votre budget sans obtenir de valeur ajoutée. Pour les équipes soucieuses de leur budget, le choix du moment et de la manière d’utiliser l’IA doit être explicite et non passif.

La dépendance excessive est un autre piège. Plus vous déléguez la compréhension à la machine, plus il devient difficile pour votre équipe de réagir avec rapidité et précision au moment le plus important. Si l’IA tombe en panne, ou pire, si elle fait une erreur à un moment critique, dans quelle mesure êtes-vous sûr que vos ingénieurs seront prêts à prendre le relais ? Si votre réponse n’est pas immédiate et claire, vous avez un fossé à combler.

En résumé : ces systèmes sont précieux, mais ce sont des outils de confiance. Déployez-les dans des limites claires. Contrôlez les coûts d’utilisation. Veillez à la transparence des scores de confiance. Et surtout, ne laissez pas l’expertise stratégique se dégrader. Lorsque l’IA échoue, seuls les humains informés comptent.

L’intégration stratégique d’outils d’intelligence artificielle est essentielle pour obtenir une grande fiabilité dans le développement de logiciels modernes.

Le passage au développement assisté par l’IA est irréversible. Les chiffres montrent déjà à quel point l’adoption est rapide : 30 % du code de Microsoft est désormais généré par des machines. Les startups vont encore plus loin, certaines s’appuyant sur l’IA pour la quasi-totalité de leur base de code. Cette rapidité oblige à repenser la manière dont la fiabilité est maintenue. Ce qui était auparavant un processus manuel, une compréhension approfondie du code, des déploiements lents, des révisions intensives, fonctionne désormais au rythme de l’automatisation.

Ce n’est pas un problème si les systèmes sont adaptés en conséquence. Les outils d’IA SRE et les plateformes d’observabilité intelligente comblent déjà certaines lacunes. Ils donnent aux équipes la capacité d’absorber les changements à grande vitesse, de traiter les données d’incidents en temps réel et de maintenir un temps de disponibilité élevé. Il ne s’agit plus d’expériences. Elles deviennent nécessaires pour suivre le rythme du bruit introduit par les déploiements générés par l’IA.

En allant plus vite, parfois de manière imprudente, les entreprises risquent également d’institutionnaliser une culture où la profondeur est remplacée par la rapidité. Cela inclut la montée de ce que certains appellent le « vibe coding », où les ingénieurs approuvent des suggestions qu’ils ne comprennent pas entièrement. Les entreprises recrutent désormais spécifiquement pour cette tâche. C’est un signe d’efficacité, mais aussi un risque pour la maintenance. Tous les systèmes finissent par atteindre des limites de complexité. À ce moment-là, une vague compréhension ne permettra pas de résoudre les vrais problèmes.

Une stratégie tournée vers l’avenir se concentre sur l’intégration de l’IA tout en maintenant la qualité et le contrôle. Cela signifie codifier l’utilisation de l’IA par des flux de travail auxquels les équipes font déjà confiance, le contrôle des versions, l’examen par les pairs, le CI/CD, la surveillance proactive. Cela signifie également qu’il faut conserver les talents d’experts qui comprennent les aspects internes du backend, les comportements des applications et les modèles de défaillance du système. Ce type de connaissances n’émerge pas par des raccourcis induits par l’IA.

Pour les dirigeants, il s’agit d’une orientation : utiliser l’IA pour répondre aux exigences de l’échelle. Mais gérez son déploiement avec discipline. Investissez dans une infrastructure qui favorise la vitesse sans sacrifier la responsabilité. Soutenez les organisations d’ingénierie pour qu’elles évoluent au même rythme que les machines, sans en devenir totalement dépendantes. Une fiabilité élevée n’est pas le résultat de l’IA seule. C’est le résultat de systèmes et de décisions intentionnels soutenus par des priorités claires. L’IA peut vous aider à atteindre ces objectifs plus rapidement, mais seulement si vous en contrôlez la direction.

Principaux enseignements pour les dirigeants

• L’IA augmente la vitesse de développement mais réduit la fiabilité : Les dirigeants doivent s’assurer que le code généré par l’IA s’exécute dans des cadres matures de CI/CD, de surveillance et de gestion du changement afin d’éviter les risques d’incidents liés à une vitesse de déploiement non contrôlée et à des bases de code gonflées.
• L’érosion des connaissances du domaine a un impact sur la réponse aux incidents : Donnez la priorité à la rétention des connaissances par le biais de l’ingénierie pratique et du développement des PME afin d’éviter que les flux de travail d’approbation de l’IA ne dégradent la familiarité avec le système et la profondeur de la résolution des incidents.
• Les outils d’IA SRE accélèrent la réponse mais ont besoin de limites : Déployez des plateformes d’incidents améliorées par l’IA pour gagner en rapidité et en visibilité, mais appliquez des politiques humaines dans la boucle et exigez des garde-fous avant d’accorder un pouvoir d’action.
• L‘IA entraîne des coûts et une exposition à la sécurité : surveillez de près l’utilisation de l’IA basée sur des jetons pour gérer les coûts, et validez les pratiques des fournisseurs en matière de données pour éviter les fuites de code propriétaire et les risques de non-conformité.
• L’échelle durable nécessite un alignement entre l’IA et l’homme : Intégrez délibérément l’IA dans les systèmes d’ingénierie, en maintenant la confiance dans les pratiques de développement et en investissant dans les talents d’experts pour garantir la fiabilité et la stabilité à long terme du système.