Toutes les organisations utilisent du code généré par l'IA en production. Ce n'est pas une projection, mais bien la conclusion du rapport « État de la sécurité des produits 2026 », qui a interrogé 400 RSSI et responsables de la sécurité applicative et a constaté une adoption à 100 %. Ce même rapport a également mis en lumière un fossé qui caractérise la situation actuelle : 81 % de ces organisations n'ont aucune visibilité complète sur l'utilisation de l'IA dans leurs bases de code. Le développement du code IA a devancé sa gouvernance, et c'est dans cet écart que réside le risque.
Ce guide aborde l'état actuel de la génération de code IA, les outils qui définiront cette catégorie en 2026, les risques spécifiques liés au code généré par l'IA, les méthodes de validation et de sécurisation, ainsi que la mise en place d'une gouvernance permettant aux équipes de développement d'utiliser l'IA rapidement sans accumuler de dette technique et de sécurité invisible. Pour les équipes d'entreprise dont les bases de code s'étendent des services cloud modernes aux systèmes mainframe existants, une dimension du codage IA est souvent négligée : que se passe-t-il lorsque la base de code que l'IA est censée comprendre et avec laquelle elle doit apporter son aide est distribuée entre COBOL, JCL, Java et Python, dans un environnement qu'aucune fenêtre de contexte ne peut contenir ?
L'IA contextuelle ne peut pas tenir, nous fournissons
SMART TS XL Cartographie chaque dépendance avant que les modifications suggérées par l'IA ne soient mises en œuvre sur l'ensemble de votre portefeuille.
EN SAVOIR PLUS…Que signifie réellement la génération de code par IA ?
Cette catégorie s'est fragmentée en trois capacités distinctes, souvent confondues mais servant des objectifs différents :
Les assistants de code IA (complétion en temps réel) suggèrent du code pendant que les développeurs saisissent leur code. GitHub Copilot, Cursor et Tabnine fonctionnent selon ce mode. Le modèle analyse le fichier dans son contexte et propose la suite. Les développeurs peuvent accepter, refuser ou modifier les suggestions directement dans le code. C'est la méthode la plus répandue et la plus éprouvée.
Le développement piloté par l'IA est la révolution qui marquera l'année 2026. Des outils comme Claude Code, GitHub Copilot Agent et Cursor en mode agent peuvent recevoir une tâche (« implémenter cette fonctionnalité », « corriger ce bug », « refactoriser ce module ») et lire des fichiers, écrire du code, exécuter des tests et itérer de manière autonome, sans intervention humaine directe. L'IA n'assiste plus le développement, elle le pilote. Les ingénieurs des plus grandes entreprises mondiales confient ainsi une part importante de leur flux de travail à des agents d'IA qui analysent les bases de code, exécutent des commandes et prennent des décisions séquentielles.
L'analyse de code par IA examine le code soumis afin de détecter les bogues, les failles de sécurité, les problèmes d'architecture et les violations de style. Des outils comme Greptile, CodeRabbit, Qodo et Cursor BugBot ajoutent des commentaires contextuels aux demandes de fusion. Contrairement à l'analyse statique traditionnelle, ils comprennent l'intention derrière le code et peuvent signaler des problèmes que les règles de correspondance de modèles ne détecteraient pas. En 2026, un processus d'analyse de code optimal confie à l'IA le rôle de premier examinateur et aux humains celui de décisionnaire, en se concentrant sur l'architecture, les risques, la maintenabilité et le jugement.
Le paysage actuel des outils
Assistants de codage IA
GitHub Copilot, initialement conçu pour la saisie semi-automatique, s'est depuis étendu aux suggestions intégrées, au chat, à l'édition de code, aux flux de travail en ligne de commande et à une interface d'agent disponible sur GitHub et les principaux éditeurs. Pour les équipes déjà présentes dans l'écosystème GitHub, l'intégration est instantanée. Enterprise Copilot ajoute des contrôles de stratégie au niveau de l'organisation, la journalisation des audits et une assurance responsabilité civile professionnelle.
Cursor est un EDI natif d'IA basé sur VS Code qui propose la saisie semi-automatique, un chat basé sur le code source et un mode agent complet. Sa capacité à indexer et à analyser de vastes bases de code le rend particulièrement performant pour les développeurs expérimentés travaillant sur des systèmes complexes et interconnectés.
Claude Code est l'agent de codage en ligne de commande d'Anthropic. Il exécute des tâches d'ingénierie complexes depuis le terminal : lecture de bases de code, écriture et modification de fichiers, exécution de tests et itérations en fonction des résultats. Fonctionnant sans interface graphique, il est particulièrement adapté aux pipelines d'automatisation et à l'intégration CI/CD.
Tabnine privilégie la confidentialité dans la complétion de code et propose des options de déploiement sur site et dans le cloud privé. Pour les entreprises des secteurs réglementés qui ne peuvent pas envoyer de code à des API externes, le modèle de déploiement de Tabnine est souvent un facteur déterminant.
Outils d'analyse de code IA
| Outil | Approche primaire | Idéal pour |
|---|---|---|
| Greptile | Contexte prenant en compte la base de code | Détection des bogues architecturaux et inter-fichiers |
| CodeLapin | Commentaires d'évaluation au niveau des relations publiques | Équipes souhaitant une automatisation des revues de relations publiques ponctuelles |
| Qodo | Génération et révision des tests | Équipes axées sur la couverture |
| Curseur BugBot | Examen basé sur les agents | équipes natives de curseur |
| SonarQube | Analyse statique + IA | Modèles basés sur des règles + indicateurs de qualité |
| SemgrepName | Analyse des motifs et des contaminations | Examen axé sur la sécurité |
| Checkmarx Assist | assainissement par agents | Programmes de sécurité des applications d'entreprise |
Voici à quoi ressemble concrètement un bon résultat d'analyse par IA :
CodeRabbit PR Review -- src/api/payments.py
WARNING HIGH: Missing input validation on amount parameter (line 23)
process_payment() accepts amount: float but does not validate
amount > 0 before calling the payment gateway.
AI-generated code from this PR omitted the boundary check present
in similar functions in src/api/orders.py (line 156).
Suggested fix: if amount <= 0: raise ValueError("Amount must be positive")
WARNING MEDIUM: Hardcoded timeout value (line 41)
requests.post(url, timeout=30) -- timeout should come from config,
not be hardcoded. See PAYMENT_GATEWAY_TIMEOUT in settings.py.
INFO: Inconsistent error handling pattern (lines 67-78)
This function raises PaymentError on failure; adjacent functions in
this module return Result[PaymentResponse, PaymentError].
Consider aligning with the module's existing pattern.Les équipes utilisant déjà SonarQube y ajoutent souvent Greptile : SonarQube gère les modèles d’analyse statique connus, tandis que Greptile détecte les bogues contextuels que l’analyse statique ne peut pas voir.
Le problème de sécurité que personne n'avait prévu
Le code généré par l'IA introduit les mêmes types de bogues que les développeurs humains (injections SQL, validation des entrées manquante, désérialisation non sécurisée, authentification défaillante), mais à une échelle bien plus importante. Si l'IA produit dix fois plus de demandes de fusion, le nombre absolu de vulnérabilités peut augmenter même si le taux de vulnérabilités par demande de fusion est identique à celui du code écrit par des humains. L'adoption massive de l'IA amplifie la dette de sécurité existante au lieu de la réduire.
Les schémas spécifiques à surveiller dans le code généré par l'IA :
Injection SQL via la complétion de modèles. Les modèles d'IA entraînés sur des bases de code existantes reproduisent les schémas hérités. Un modèle ayant analysé des milliers d'exemples de requêtes SQL concaténées suggérera des requêtes similaires. Sans instruction explicite d'utiliser des requêtes paramétrées et sans analyse statique pour l'imposer, le code SQL généré par l'IA peut introduire systématiquement des vulnérabilités d'injection dans une base de code.
python
# What AI often generates without explicit security prompting
def get_user(username: str) -> dict:
query = f"SELECT * FROM users WHERE username = '{username}'"
return db.execute(query).fetchone()
# Vulnerable to: admin'-- or admin' OR '1'='1
# What AI generates when security requirements are stated in the prompt
def get_user(username: str) -> dict:
query = "SELECT id, email, role FROM users WHERE username = %s"
return db.execute(query, (username,)).fetchone()
# Parameterized -- injection-proof regardless of inputLa différence entre ces deux résultats tient à une seule phrase dans l'invite : « utilisez une requête paramétrée pour éviter les injections SQL ». Sans cette invite, le modèle utilise par défaut l'interpolation de chaînes car il a rencontré davantage d'exemples d'interpolation de chaînes que de requêtes paramétrées dans ses données d'entraînement.
Validation des entrées manquante. Les modèles d'IA sont optimisés pour produire du code fonctionnel, c'est-à-dire du code qui fonctionne avec les entrées spécifiées dans l'invite. Ils omettent systématiquement la validation des cas limites, des conditions aux limites et des entrées malformées non mentionnées dans le contexte de l'invite. Le code résultant réussit les tests générés simultanément, mais échoue face à des entrées adverses réelles.
Paramètres par défaut non sécurisés. Le code d'IA configure fréquemment les paramètres de sécurité avec les valeurs les plus permissives : vérification des certificats désactivée, origines CORS génériques, identifiants de développement conservés, car ces paramètres par défaut permissifs permettent au code de « fonctionner » dans davantage de contextes, ce pour quoi le modèle est optimisé.
Risque lié aux licences. Les modèles d'IA générative entraînés sur du code public peuvent reproduire des extraits de code proches ou identiques à leurs données d'entraînement, ce qui soulève des questions de licence lorsque ces données sont sous licence copyleft. De nombreux outils d'entreprise proposent désormais des filtres de licence, la détection des références au code et des clauses d'indemnisation, mais la couverture varie. Vérifiez les fonctionnalités incluses par votre outil spécifique plutôt que de faire des suppositions.
Lacune en matière de gouvernance : 81 % des organisations utilisant du code généré par IA en production n’ont qu’une visibilité partielle sur son utilisation. La gouvernance, qui consiste à identifier le code généré par IA, à le valider par analyse statique et à appliquer les politiques de sécurité lors de la validation, représente un travail que la plupart des entreprises adoptant le développement basé sur l’IA n’ont pas encore réalisé.
Langages de programmation pour l'IA : ce que le modèle comprend réellement
Python et TypeScript : Assistance optimale
Python et TypeScript offrent la représentation des données d'entraînement la plus dense dans tous les principaux modèles de programmation d'IA. Ces modèles comprennent les schémas idiomatiques, les conventions courantes des bibliothèques et les bonnes pratiques spécifiques aux frameworks. Les suggestions de code en Python et TypeScript sont les plus fiables, les moins susceptibles d'interpréter des API inexistantes et les plus à même de respecter les meilleures pratiques de sécurité.
La position dominante de Python dans le développement de l'IA et du ML en fait le langage de prédilection des équipes concevant des systèmes basés sur l'IA. Son écosystème, composé de PyTorch, TensorFlow, Hugging Face et LangChain, est parfaitement maîtrisé par tous les principaux modèles de programmation.
Java et C# : puissants mais verbeux
Java et C# disposent de vastes ensembles de données d'entraînement provenant de bases de code open source et de Stack Overflow. Les outils d'IA produisent du code fonctionnellement correct dans les deux langages, mais peuvent suggérer des modèles inutilement verbeux. Les configurations ORM, les paramétrages d'injection de dépendances et le code standard des frameworks qui rendent Java et C# prêts pour la production nécessitent un contexte spécifique que les modèles ne perçoivent parfois pas sans intervention explicite.
Go, Rust et Kotlin : une croissance rapide
La simplicité de Go et la gestion explicite de la mémoire en Rust présentent toutes deux des défis intéressants pour les modèles d'IA. Les suggestions de Go sont généralement fiables ; celles de Rust s'améliorent rapidement mais nécessitent encore une vérification humaine approfondie, notamment en ce qui concerne la gestion de la durée de vie des données et les blocs non sécurisés.
Langages hérités : COBOL, RPG, PL/I
C’est une dimension que la plupart des guides de programmation IA négligent. Les grandes entreprises qui utilisent COBOL sur mainframe, RPG sur IBM i et PL/I dans leurs systèmes financiers sont confrontées à un défi spécifique en matière de programmation IA, que les modèles généralistes peinent à relever. Les données d’entraînement pour ces langages sont rares par rapport à leur utilisation en production. Les modèles d’IA font des suggestions syntaxiques COBOL qui, bien que grammaticalement plausibles, sont sémantiquement incorrectes, ou qui fonctionnent isolément mais enfreignent les contraintes de couplage des programmes avec lesquels elles s’exécutent.
Plus important encore : la limitation de la fenêtre de contexte empêche un modèle d’IA de gérer simultanément en mémoire un vaste ensemble de programmes COBOL. Il peut visualiser le programme en cours d’édition, mais pas les copybooks partagés avec 300 autres programmes, la tâche JCL qui l’appelle, ni le schéma DB2 dont il dépend. Pour que l’IA puisse assister efficacement les modifications de code existant, le contexte structurel manquant dans la fenêtre de contexte doit provenir d’une couche d’analyse structurelle capable de comprendre l’intégralité du graphe de dépendances.
Rédiger de meilleures invites pour un meilleur code
La qualité du code généré par l'IA est directement proportionnelle à la spécificité de la consigne. Des consignes vagues produisent un code générique ; des consignes spécifiques produisent un code ciblé et correct.
Incluez explicitement les exigences de sécurité. Par défaut, les modèles d'IA génèrent du code fonctionnel. « Écrivez une fonction qui interroge la base de données par identifiant utilisateur » produira du SQL concaténé. « Écrivez une fonction qui interroge la base de données par identifiant utilisateur en utilisant des requêtes paramétrées pour prévenir les injections SQL » produira du SQL paramétré. Les exigences de sécurité doivent être énoncées, et non présumées.
Voici la même tâche avec et sans cadre de sécurité :
# Vague prompt (produces insecure code):
"Write a function to get a user from the database by username"
# Specific prompt (produces secure, production-ready code):
"Write a Python function get_user(username: str) -> Optional[UserRecord]
that queries the PostgreSQL users table using a parameterized query
to prevent SQL injection. Return None if not found. Raise DatabaseError
on connection failure. Do not SELECT * -- return only id, email, and role."Spécifiez le framework et sa version. « Écrire un gestionnaire de route Express.js » donne des résultats différents de « Écrire un gestionnaire de route Express 4.18 qui utilise async/await, valide les entrées avec zod et renvoie des réponses typées ». Plus le contexte du framework est précis, moins le modèle a besoin de deviner.
Fournissez l'interface, pas seulement la tâche. Au lieu de « écrire une fonction de traitement des paiements », spécifiez le type d'entrée, le type de sortie, les conditions d'erreur et les dépendances : « Écrivez une fonction TypeScript ». processPayment(amount: number, currency: 'USD'|'EUR', customerId: string): Promise<PaymentResult> qui appelle notre classe interne PaymentGateway et gère spécifiquement les erreurs INSUFFICIENT_FUNDS et CARD_DECLINED.
Référencez le code adjacent. Dans les outils capables de lire l'intégralité du fichier ou du projet, fournir les interfaces, les types et les modèles existants associés permet au modèle de produire un code cohérent et idiomatique plutôt qu'un code générique inadapté à la base de code existante.
Validation du code généré par l'IA : la pile de contrôle qualité
Le code généré par l'IA doit subir la même validation, voire une validation plus rigoureuse dans de nombreux cas, que le code écrit par des humains. L'argument du volume s'applique aussi bien à la qualité qu'à la sécurité : si l'IA produit plus de code plus rapidement, les mécanismes de détection des problèmes doivent être tout aussi rapides et plus systématiques.
L'analyse statique est obligatoire. L'analyse statique, l'analyse SAST, l'analyse des dépendances, l'analyse des secrets et les politiques de non-approbation des commits générés par l'IA constituent les mesures d'atténuation standard des risques liés à la qualité du code IA. Cela implique l'exécution d'outils tels que ESLint, Pylint, SonarQube, Semgrep ou équivalents sur chaque pull request, que le code soit écrit par un humain ou généré par une IA.
yaml
name: AI Code Quality Gate
on: [pull_request]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Static analysis (same rules for AI and human code)
run: |
pip install ruff bandit
ruff check src/ # style + quality
bandit -r src/ -ll # security patterns
- name: SAST scan
uses: semgrep/semgrep-action@v1
with:
config: p/owasp-top-ten p/python
- name: Stricter gate for AI-generated PRs
if: contains(github.event.pull_request.labels.*.name, 'ai-generated')
run: |
echo "AI-generated PR -- enforcing senior-engineer review requirement"
# Blocks merge until human approval from codeownerL'analyse par IA des demandes de fusion générées par l'IA ajoute une couche supplémentaire. L'exécution de CodeRabbit ou de Greptile sur une demande de fusion générée par l'IA permet de détecter les problèmes contextuels que l'analyse statique ne repère pas, les erreurs de logique, les cas limites non couverts et les incohérences architecturales avec le reste du code.
La génération de tests en parallèle de la génération de code est désormais la norme dans les flux de travail automatisés. Claude Code, GitHub Copilot Agent et d'autres outils similaires peuvent générer des tests au sein du même flux de travail que celui qui génère le code. Il convient d'examiner les tests avec le même scepticisme que le code : les tests générés par l'IA sont optimisés pour les métriques de couverture et peuvent tester l'implémentation telle qu'elle est écrite plutôt que la spécification telle qu'elle était prévue.
L'architecture et les risques font l'objet d'une revue humaine. L'IA effectue une première vérification de la conformité mécanique. Les examinateurs humains prennent les décisions finales : cette abstraction est-elle pertinente ? Introduit-elle une nouvelle dépendance souhaitable ? La gestion des erreurs est-elle adaptée au niveau de sécurité ? Il s'agit d'une répartition des responsabilités optimale, et non d'une solution temporaire en attendant la maturation de l'IA.
Code d'IA dans les environnements d'entreprise : le problème de la fenêtre de contexte
La fenêtre de contexte correspond à la quantité limitée de texte qu'un modèle peut traiter simultanément. En 2026, certains modèles de pointe proposaient des fenêtres de contexte approchant le million de jetons, suffisantes pour gérer un petit service de bout en bout. Une fenêtre d'un million de jetons contient environ quatre mégaoctets de texte. Les monorépos d'entreprise, quant à eux, peuvent atteindre plusieurs gigaoctets. Pour les bases de code supérieures à quatre mégaoctets environ, la recherche globale et l'analyse du code sont indispensables pour la plupart des requêtes.
Il ne s'agit pas d'une critique des modèles d'IA, mais d'une contrainte architecturale qui détermine le déploiement des outils de codage IA en entreprise. La couche de récupération qui complète la fenêtre de contexte, la plateforme d'analyse du code qui comprend l'intégralité du graphe de dépendances et récupère le contexte pertinent pour chaque requête IA, est ce qui rend le codage IA viable dans les bases de code volumineuses et complexes.
Pour les organisations disposant de systèmes mainframe hérités, le défi est encore plus grand. Les relations de dépendance entre les programmes COBOL, les flux de travaux JCL, les schémas DB2 et les services Java modernes sont invisibles pour un modèle qui ne peut voir que ce qui tient dans sa fenêtre de contexte. Un assistant IA aidant un développeur à modifier un programme COBOL ne peut pas savoir que le champ qu'il suggère de renommer apparaît dans 47 autres programmes via un copybook partagé, à moins que cette information structurelle ne lui soit fournie en externe.
Le contraste entre une invite sans contexte et une invite riche en contexte pour une modification existante illustre pourquoi les connaissances structurelles sont importantes :
# Without structural context -- what AI sees in isolation:
"Refactor the calculateInterest paragraph in ACCTPROC.cbl
to reduce cyclomatic complexity"
# With structural context from dependency analysis:
"Refactor the calculateInterest paragraph in ACCTPROC.cbl.
Note: this paragraph is called by 14 other programs via CALL.
It shares WS-ACCT-RATE from copybook INTRATES.cpy (included by 47 programs).
The WS-COMPOUND-FLAG field used in lines 340-360 is set by ACCTINIT.cbl
before this runs -- do not move or rename it.
Do not change field names, parameter order, or RETURN-CODE values --
these are interface contracts with callers."La deuxième invite produit une refactorisation déployable en toute sécurité. La première en produit une qui, bien que syntaxiquement correcte, peut néanmoins perturber 14 programmes appelants dont l'IA ignorait l'existence.
Comment SMART TS XL Prend en charge le développement assisté par l'IA dans les bases de code d'entreprise
SMART TS XL fournit la couche de contexte structurel dont les outils de codage IA ont besoin pour fonctionner en toute sécurité dans de vastes bases de code d'entreprise multilingues.
Lorsqu'un outil d'IA suggère une modification à un programme COBOL, SMART TS XL's cartographie des dépendances des applications Elle fournit le contexte de dépendance que la fenêtre de contexte de l'IA ne peut pas contenir : les copybooks inclus par le programme, les autres programmes qui l'appellent, les jeux de données qu'il produit, les tâches JCL qui l'invoquent et dans quel ordre. Cette connaissance structurelle est indispensable pour que la suggestion de l'IA soit considérée comme sûre et non seulement correcte localement.
SMART TS XL's analyse de code statique Ce système valide avec la même rigueur le code généré par l'IA et le code écrit par des humains, calculant des indicateurs de qualité, identifiant les failles de sécurité, signalant le code mort et mesurant la complexité simultanément dans tous les langages de l'environnement. Pour les organisations ayant adopté des outils de codage IA et qui gèrent désormais la qualité de leur code, cette mesure de qualité multilingue constitue la validation systématique qu'une revue de code ponctuelle ne peut fournir à grande échelle.
La capacité d'analyse d'impact répond à une question que les outils d'IA ne peuvent pas résoudre : si cette modification suggérée par l'IA est acceptée, quelles autres parties du système seront affectées ? Le périmètre d'impact – chaque programme dépendant, chaque consommateur en aval, chaque test à revalider – est déterminé à partir du modèle structurel du code source, et non par l'interprétation qu'en fait le modèle d'IA. Pour les modifications qui impliquent plusieurs langages, c'est ce qui fait la différence entre un déploiement en toute confiance et la découverte des conséquences en production.
La fonction de recherche d'entreprise permet d'interroger l'intégralité du code source, palliant ainsi les limitations du contexte de l'IA : elle permet de trouver en quelques secondes chaque référence à une structure de données, chaque utilisation d'une API obsolète, chaque programme interagissant avec un ensemble de données spécifique, et ce, sur des millions de lignes de code, quel que soit le langage utilisé. C'est grâce à cette fonction de recherche que les outils de codage pour l'IA peuvent extraire le contexte pertinent nécessaire aux requêtes complexes sur le code source d'entreprise, au lieu de travailler à partir d'une vision incomplète.
Le cadre de gouvernance
Les organisations qui utiliseront efficacement le codage de l'IA en 2026 auront bâti leur gouvernance autour de celui-ci, et non autour de restrictions. Ce cadre comporte quatre composantes :
Visibilité. Identifiez le code généré par l'IA dans votre base de code. Certains outils permettent d'étiqueter les commits générés par l'IA ; d'autres exigent l'application de politiques via des hooks de commit ou des modèles de pull request. Sans visibilité, l'écart de 81 % (les organisations qui ignorent où l'IA est à l'œuvre) persiste.
Validation systématique. Appliquez les mêmes normes d'analyse statique, d'analyse de sécurité et de revue de code au code généré par l'IA qu'au code écrit par des humains. N'exemptez pas les demandes de tirage générées par l'IA des contrôles qualité sous prétexte qu'elles « proviennent de l'IA ».
Normes de génération de code structurées. Définissez les pratiques de génération de code utilisées par vos équipes : contexte requis, exigences de sécurité et frameworks à spécifier. Ce contrôle qualité des données d'entrée garantit la constance de la qualité des données de sortie.
La responsabilité humaine est essentielle pour les décisions architecturales. L'IA détermine la validité technique, tandis que les humains déterminent la pertinence architecturale. Préservez cette distinction de manière explicite dans votre processus de développement, plutôt que de la laisser s'estomper avec l'accélération de l'adoption de l'IA.
L'IA écrit le code. Vous en subissez toujours les conséquences.
Le codage par IA est passé du stade expérimental à celui d'infrastructure. La question n'est plus de savoir s'il faut utiliser des outils de génération de code par IA : le marché a tranché, et l'adoption à 100 % par les entreprises le confirme. La question est de savoir si l'infrastructure de gouvernance nécessaire pour garantir la sécurité et la pérennité du codage par IA à l'échelle de l'entreprise a été mise en place parallèlement à cette adoption.
Le volume de code généré par l'IA est en constante augmentation. Les mécanismes de validation, d'analyse statique, d'analyse de sécurité, de revue de code par l'IA et de revue architecturale humaine doivent évoluer en conséquence. Pour les entreprises dont le code source inclut des langages que les modèles d'IA généralistes maîtrisent mal, la couche d'analyse structurelle, qui fournit le contexte des dépendances et l'étendue de l'impact, est essentielle pour que l'assistance par l'IA soit viable et non dangereuse.
