Aller au contenu
Promptique

Rechercher dans Promptique
Guides

L’IA dans le développement logiciel : assistants, agents, qualité

Complétion, assistant, agent multi-fichiers ou autonome : ce guide aide à choisir le bon niveau d’assistance, préserver la qualité et mesurer le gain réel.

Promptique21 août 202624 min de lecture
Deux développeurs relisant ensemble du code affiché sur un ordinateur portable

L’assistance par IA au code recouvre quatre pratiques distinctes – complétion en ligne, dialogue dans l’éditeur, agent multi-fichiers, agent autonome en intégration continue – qui n’apportent ni les mêmes gains, ni les mêmes risques, ni la même charge de vérification. Les confondre est la première cause de déception.

Le débat public oppose deux récits peu utiles : l’IA écrirait bientôt tout le code, ou elle ne produirait que du bruit. Les mesures disent autre chose. Le rapport DORA 2025, fondé sur près de 5 000 réponses, décrit un amplificateur : l’IA accélère la production et révèle les goulots situés en aval, dans la revue et les tests. Un essai contrôlé publié par METR en juillet 2025 a mesuré un ralentissement chez des développeurs expérimentés sur des dépôts familiers, alors qu’ils se croyaient accélérés.

Cet article ne tranche pas « pour » ou « contre ». Il donne une grille : quel niveau d’assistance pour quelle tâche, quel contexte fournir, quels garde-fous poser, comment mesurer. Vous saurez ensuite classer vos tâches, écrire un fichier de règles projet, déléguer en six étapes vérifiables et choisir des indicateurs utiles.

L’essentiel en 60 secondes

  • Quatre niveaux d’assistance coexistent. Chacun déplace le travail humain de l’écriture vers la spécification et la vérification.
  • Plus l’outil est autonome, plus la revue devient le goulot. Accélérer l’écriture sans renforcer la vérification avance seulement la date du problème.
  • Le contexte fourni peut peser autant ou davantage que le choix du modèle ; mesurez sur vos tâches l’effet d’un fichier de règles versionné.
  • Le gain est réel là où la vérification est bon marché : tests, migrations mécaniques, code répétitif, documentation, exploration d’un dépôt inconnu.
  • Il est faible ou négatif sur l’architecture, la concurrence, le code métier peu documenté et la sécurité fine.
  • Le risque central n’est pas le code faux, mais le code plausible accepté sans lecture, qui crée une dette de compréhension invisible dans le diff.
  • Les tests sont une condition d’entrée : sans filet automatisé, vous perdez votre seul mécanisme d’alerte.
  • La sécurité se traite en quatre volets : secrets, dépendances inventées, licences du code suggéré, code envoyé à un tiers.
  • L’auto-hébergement peut réduire l’exposition du code si vous contrôlez aussi les journaux, la télémétrie, les dépendances, les accès et le réseau ; il n’améliore pas la qualité par lui-même.
  • Mesurez le délai de cycle, les retours en revue, le taux d’échec des changements et les incidents. Jamais des lignes de code.

À retenir : un assistant de code ne remplace pas la compréhension du système, il déplace le travail vers la spécification et la vérification, et il n’est rentable que si vous outillez ces deux extrémités.

Sommaire

Les quatre niveaux d’assistance au code

La question utile n’est pas « quel outil » mais « quelle unité de travail vous déléguez ». Cette unité détermine ce que vous devez vérifier et le coût d’une erreur qui passe.

Niveau Ce que l’outil produit Unité déléguée Ce que vous vérifiez Coût d’une erreur non vue
1. Complétion en ligne Fin de ligne, bloc court Quelques lignes Lecture immédiate, à la frappe Faible et local
2. Dialogue dans l’éditeur Explication, correction ciblée Une fonction Le raisonnement et le diff proposé Modéré, localisé
3. Agent multi-fichiers Un diff sur plusieurs fichiers Une tâche Le plan, le diff, les tests Élevé : la revue devient le goulot
4. Agent autonome en intégration continue Une proposition de fusion complète Un ticket La spécification, puis la proposition rendue Élevé et différé

Aux niveaux 1 et 2, votre attention reste sur le code et la vérification est quasi gratuite. Le risque est l’acceptation réflexe d’une proposition correcte à la lecture mais fausse : inversion d’arguments, unité erronée, condition de bord ignorée. Le gain du niveau 2 tient moins à l’écriture qu’à l’explication ; les principes de notre guide du prompt engineering s’y appliquent tels quels.

Au niveau 3, votre attention quitte le code pour un diff : vous ne suivez plus la construction, vous jugez un résultat. Tout dépend alors de deux éléments écrits avant le lancement, le périmètre autorisé et le critère d’acceptation. Au niveau 4, l’agent travaille sans vous et le travail humain se concentre aux extrémités. C’est la discipline exposée dans notre guide des agents IA et de MCP.

Le paysage des outils en août 2026

Un classement serait périmé avant publication : les produits changent de nom, de propriétaire et de modèle en quelques mois. Windsurf en donne un exemple : racheté par Cognition, l’éditeur a été rebaptisé Devin Desktop en juin 2026, et au 21 août 2026 windsurf.com redirige vers devin.ai/desktop. Raisonnez par catégorie de capacité, avec la même grille de questions.

Catégorie de capacité Outils représentatifs Question à poser avant d’adopter
Complétion et édition en ligne GitHub Copilot, Cursor, Devin Desktop Quel filtrage des correspondances avec du code public ?
Éditeur agentique Cursor, Devin Desktop (ex-Windsurf), Zed Le dépôt est-il indexé côté serveur, et où ?
Agent en terminal Claude Code, Codex CLI, Gemini CLI, Aider Quels droits sur les fichiers et le réseau ?
Agent délégué (hébergé ou en intégration continue) Agent de codage Copilot, Codex, Gemini Code Assist Quel pare-feu sortant, quelle approbation avant exécution ?
Extension ouverte, modèle au choix Continue, Aider Quel modèle, quel hébergement, quel coût par tâche ?

Deux standards réduisent le coût de changement d’outil. MCP, passé à la spécification stable du 28 juillet 2026, normalise la connexion d’un modèle à vos outils et données ; voir notre article sur la migration vers MCP 2026-07-28. Le protocole ACP, publié par Zed Industries en août 2025 sous licence Apache 2.0, normalise l’autre extrémité : un éditeur pilote n’importe quel agent compatible via JSON-RPC 2.0. Investissez dans ce qui est portable – règles, serveurs MCP, scripts de vérification – et tenez l’interface pour remplaçable. Le choix du modèle relève de notre comparatif ChatGPT, Claude, Gemini et Mistral.

Donner du contexte à un assistant de code

Un modèle qui ignore vos conventions, votre arborescence et vos commandes de test produit souvent du code générique. Un contexte permanent versionné avec le dépôt peut être un levier plus rentable que la reformulation répétée de chaque demande ; vérifiez cette hypothèse sur vos tâches et vos outils.

Les formats de fichiers de règles

AGENTS.md s’est imposé comme dénominateur commun : un fichier Markdown sans champ obligatoire, à la racine du dépôt. Le site du format revendique plus de 60 000 projets open source et liste une vingtaine d’outils compatibles ; ce décompte auto-déclaré, dérivé d’une recherche de code sur GitHub, mesure la présence d’un fichier, pas son utilité. En monorepo, l’agent lit le fichier le plus proche du fichier modifié. Les formats spécifiques servent à conditionner les règles :

  • Claude Code : CLAUDE.md, hiérarchie personnelle, projet et sous-répertoire.
  • Cursor : .cursor/rules/*.mdc, dont l’en-tête description, globs et alwaysApply détermine si la règle s’applique toujours ou à certains chemins. AGENTS.md est aussi lu.
  • GitHub Copilot : .github/copilot-instructions.md, et des .github/instructions/*.instructions.md dont l’en-tête applyTo cible des chemins.
  • Gemini Code Assist et Gemini CLI : GEMINI.md, complété par un fichier global dans ~/.gemini/.
  • Aider : un CONVENTIONS.md chargé en lecture seule via --read, donc réutilisable d’une session à l’autre.
  • Continue : un répertoire .continue/rules, un fichier par règle, versionné avec le dépôt.

Ce qu’il faut y écrire

Un fichier utile contient ce que l’outil ne peut pas déduire du code : commandes exactes, invariants métier, zones interdites, décisions déjà prises. Ni conseils généraux de programmation, ni reformulation de ce que l’analyseur statique impose déjà ; chaque ligne consomme de la fenêtre de contexte. Traitez-le comme du code : relu en revue, corrigé, testé. Une règle ignorée deux fois est mal placée ou trop vague. La logique de non-régression de notre article sur l’évaluation d’un prompt s’applique ici.

# AGENTS.md

S'applique à tout le dépôt. Un AGENTS.md plus proche du fichier modifié a priorité.

## Le projet en cinq lignes
- Produit : API de facturation multi-devises, trois applications internes.
- Langage : TypeScript strict, Node 22. Pas de `any`, pas de `@ts-ignore`.
- Architecture : `src/domain` (métier pur) -> `src/app` -> `src/infra`, dans ce sens.
- Persistance : PostgreSQL, migrations dans `db/migrations`. Aucun DDL hors migration.
- Montants en centimes entiers. Aucun flottant pour de l'argent.

## Commandes
- Installer : `pnpm install --frozen-lockfile`
- Vérifier avant de rendre : `pnpm lint && pnpm typecheck && pnpm test`
- Test ciblé : `pnpm test -- src/domain/invoice.test.ts`

## Règles de modification
1. Lisez les tests existants du module avant d'écrire du code.
2. Une tâche produit un diff cohérent. Ne reformatez pas de fichiers hors sujet.
3. Toute correction de bogue commence par un test qui échoue.
4. N'ajoutez aucune dépendance sans la proposer et justifier le besoin.
5. Ne modifiez jamais une migration appliquée : créez-en une nouvelle.
6. Interdits : appel réseau dans `src/domain`, journalisation hors `src/infra/logging`.

## Ce que vous ne pouvez pas deviner
- `src/legacy/pricing.ts` est déprécié mais appelé par deux clients externes :
  ne le refactorez pas, ne changez pas sa signature.
- Les codes d'erreur exposés sont un contrat public : ne les renommez pas.
- Le fuseau de référence est UTC.

## En cas de blocage
Posez la question plutôt que d'inventer une interface. Écrivez toute supposition
sous la forme « hypothèse : ... ».

Où le gain est réel, où il ne l’est pas

Le critère pratique à tester est le coût de vérification du résultat. Une vérification fiable et peu coûteuse rend souvent l’assistance plus intéressante malgré un taux d’erreur non nul ; sans elle, chaque proposition plausible ajoute du temps d’analyse. Le tableau suivant est une heuristique de priorisation, pas une mesure généralisable : calibrez ses niveaux sur vos dépôts.

Tâche Gain attendu Risque dominant
Tests sur code existant Élevé Tests qui figent le bogue au lieu de le détecter
Migration mécanique Élevé Cas particuliers traités comme le cas général
Code répétitif d’infrastructure Élevé Duplication au lieu de factorisation
Documentation, messages de commit Élevé Intention supposée plutôt que code réel
Revue de première passe Moyen à élevé Faux positifs nombreux, silence sur le fond
Exploration d’un dépôt inconnu Moyen à élevé Explication fluide mais inexacte
Conception d’architecture Faible Solution générique, hors de vos contraintes
Débogage de concurrence Faible à négatif Diagnostic plausible sans preuve
Code métier peu documenté Faible à négatif Invention de règles de gestion
Sécurité fine, cryptographie Négatif sans revue experte Code qui compile et reste vulnérable

Garde-fou générique : ne déléguez que ce dont vous pouvez faire échouer la vérification à volonté.

La dernière ligne mérite des chiffres datés. Le GenAI Code Security Report de Veracode fait produire du code par des modèles sur des tâches dont la faiblesse de sécurité attendue est connue, puis analyse le résultat. Dans la mise à jour du 24 mars 2026, 55 % des générations passent les contrôles de sécurité, sur 80 tâches et quatre langages, pour une justesse syntaxique supérieure à 95 %. Dans l’édition du 28 juillet 2026, la moyenne est de 56 % et le meilleur modèle de la vague atteint 68 %. Ces mesures proviennent d’un éditeur de solutions de sécurité, non d’une évaluation indépendante ; retenez leur ordre de grandeur comme signal à vérifier sur vos propres tâches, pas comme taux attendu.

Déléguer une tâche à un agent en six étapes

Aux niveaux 3 et 4, l’objectif est unique : rendre la vérification moins coûteuse que l’écriture.

  1. Découper jusqu’à une tâche vérifiable. Si vous ne pouvez pas décrire en une phrase le test qui prouvera la réussite, la tâche est trop grosse.
  2. Écrire le critère d’acceptation avant le prompt. Comportement attendu, cas limites, et ce qui doit rester inchangé. Ce texte servira aussi de base à votre revue.
  3. Fixer le périmètre. Fichiers autorisés, fichiers interdits. Sans périmètre, l’agent reformate et renomme des zones que personne ne voulait rouvrir.
  4. Demander un plan avant le code. Un plan en cinq points coûte peu de jetons (tokens) et révèle immédiatement un malentendu.
  5. Exiger la trace des vérifications. L’agent lance analyse statique, types et tests, et rend la sortie réelle. Une réussite affirmée sans sortie de commande ne vaut rien.
  6. Relire le diff comme celui d’un inconnu, puis itérer sur un seul point. Une demande globale de correction fait perdre la traçabilité des changements.

La revue de code assistée et ses angles morts

Un outil de revue lit un diff, pas un système. Il repère bien le local et le normatif : nommage incohérent, erreur non gérée, valeur non validée, ressource non fermée. Ses angles morts sont structurels.

  • Le contexte hors du diff. Il ne voit ni l’appelant d’un autre dépôt, ni la contrainte de compatibilité ascendante, ni la décision d’architecture prise deux ans plus tôt.
  • L’intention. Il ne dira pas que la fonctionnalité livrée n’est pas celle qui était demandée, le défaut le plus coûteux.
  • Ce qui manque. Test absent, cas d’usage oublié, migration non écrite ne produisent aucune ligne dans le diff.
  • L’effet de volume. Une liste de remarques mineures détourne l’attention du seul point de fond.
  • La complaisance. L’agent qui a écrit le code valide sa propre logique : celui qui écrit ne doit jamais approuver.

Cet avis ne bloque ni n’approuve seul une fusion : il fixe l’ordre du jour de la revue humaine.

La dette de compréhension

Le risque le plus discret n’est pas le code faux : c’est le code juste que personne ne comprend. Il passe les tests, part en production, et devient impossible à modifier six mois plus tard.

GitClear, qui analyse l’historique de dépôts réels, mesure sur 623 millions de changements entre 2023 et 2026 une hausse continue des blocs dupliqués – 73,0 par million de lignes modifiées en 2026, environ 81 % de plus qu’en 2023 – pendant que la part des lignes déplacées, indicateur de remaniement, tombe à 3,8 % contre 21 % en 2022. Deux réserves : la recherche émane d’un éditeur d’outil d’analyse de code, et la composition de l’échantillon de dépôts n’est pas documentée publiquement. Ces données restent corrélationnelles : elles indiquent une direction à vérifier sur vos propres dépôts, où les deux indicateurs sont calculables, pas une causalité établie.

Trois pratiques limitent cette dette : ne pas fusionner un changement que personne ne peut expliquer ; écrire des commits qui disent pourquoi et non quoi ; relire la zone modifiée quelques jours plus tard, sans assistant.

Les tests, filet de sécurité non négociable

L’assistance augmente le débit de changements sans augmenter votre capacité à en détecter les effets. Le rapport DORA 2025 le formule utilement : l’IA agit comme un amplificateur des forces et des faiblesses déjà présentes. Une équipe faiblement couverte amplifie sa fragilité. L’ordre des opérations compte donc : sur un module sans tests, ne demandez pas une refonte, mais des tests de caractérisation qui figent le comportement actuel ; vérifiez-les à la main, puis déléguez la modification.

Quatre exigences minimales : une commande unique qui lance toutes les vérifications ; des tests déterministes, sans dépendance à l’horloge ni au réseau ; une exécution assez rapide pour ne pas être contournée ; un test de non-régression après chaque incident. Le droit de répondre « je ne sais pas » plutôt que d’inventer, central face aux hallucinations des IA génératives, se traduit ici par une consigne du fichier de règles.

Sécurité, secrets, dépendances et licences

Quatre risques distincts, quatre traitements. Les regrouper sous « la sécurité de l’IA » conduit à n’en traiter aucun.

Les secrets

Un assistant lit ce que vous lui donnez et, selon la configuration, ce qu’il trouve dans l’arborescence : un .env non ignoré, une clé dans un test, un jeton dans un historique. Mesures classiques : détection de secrets en pré-commit et en intégration continue, exclusions d’indexation, rotation immédiate en cas de doute. Pour un agent autonome, contrôlez aussi le trafic sortant. L’agent de codage de GitHub illustre le montage attendu : environnement éphémère, pare-feu sortant à liste d’autorisation, approbation par une personne disposant du droit d’écriture avant l’exécution des chaînes déclenchées par ses propositions de fusion. Vérifiez le périmètre du pare-feu : celui de GitHub ne couvre ni les serveurs MCP configurés, ni les étapes d’installation personnalisées.

Les dépendances inventées et le slopsquatting

Un modèle peut suggérer un paquet qui n’existe pas. L’étude We Have a Package for You, présentée à USENIX Security 2025, a analysé 576 000 échantillons de code générés par 16 modèles : 19,7 % des paquets suggérés n’existaient pas, avec un écart marqué entre modèles commerciaux (5,2 %) et modèles à poids ouverts (21,7 %). En rejouant dix fois une requête ayant produit un nom inventé, 43 % de ces noms réapparaissaient à chaque exécution. Cette reproductibilité rend l’attaque viable : un tiers enregistre le nom inventé sur le registre public et attend. La pratique a été nommée slopsquatting par Seth Larson, de la Python Software Foundation. Parades : validation humaine de tout ajout de dépendance, versions verrouillées, miroir interne.

Les licences du code suggéré

Un modèle entraîné sur du code public peut restituer un extrait proche d’une source sous licence contraignante. GitHub documente la référence au code public : Copilot compare une suggestion potentielle et environ 150 caractères de contexte à un index de dépôts publics. Selon la politique choisie, une correspondance est écartée ou proposée avec une référence vers les fichiers publics concernés et, lorsqu’elle est détectée, leur licence. La documentation actuelle ne publie pas de seuil de 65 lexèmes. Le dispositif ne couvre pas toutes les reformulations ; décidez du réglage et documentez-le avec votre conseil juridique.

Le code d’entreprise envoyé à un tiers

Le sujet est contractuel avant d’être technique : qui traite les données, où, combien de temps et avec quel usage d’entraînement. Les obligations sont détaillées dans notre guide de l’IA générative en entreprise face au RGPD et à l’AI Act. Au minimum : exclusion d’entraînement écrite et liste des dépôts non éligibles. Enfin, un agent qui lit des tickets ou des pages web est exposé à l’injection de prompt (LLM01), dont l’impact augmente lorsqu’il dispose d’une agentivité excessive (LLM03). Dans l’édition 2026 de l’OWASP GenAI LLM Top 10, LLM06 désigne la consommation non bornée. Tout contenu externe est une donnée, jamais une instruction.

Auto-héberger un assistant de code

L’auto-hébergement peut répondre à une contrainte de résidence du code, à condition de contrôler aussi les journaux, la télémétrie, les dépendances, les accès et le réseau sortant. Il ne règle ni la qualité ni le coût à court terme. Le montage courant associe un moteur d’inférence local, un modèle à poids ouverts orienté code et un client compatible, par exemple Continue ou Aider. Points de vigilance : mémoire de la carte graphique, fenêtre de contexte exploitable, latence à la frappe et coût d’exploitation ; voir notre guide de l’IA locale en 2026. Un scénario mixte peut être plus réaliste : complétion locale, tâches agentiques chez un fournisseur sous contrat et dépôts sensibles exclus.

Mesurer l’impact réel

La plupart des déploiements échouent ici : ils mesurent la production au lieu de la livraison. Lignes de code, suggestions acceptées et satisfaction déclarée mesurent l’activité de l’outil, pas son effet. Sur ce dernier point, l’essai randomisé de METR publié le 10 juillet 2025 reste l’exemple le plus net : 16 développeurs open source expérimentés, 246 tâches réelles dans des dépôts qu’ils maîtrisaient, des tâches 19 % plus longues avec assistance, alors qu’ils estimaient a posteriori avoir gagné environ 20 %.

Ce résultat se lit avec ses bornes, que METR pose elle-même : outils du début 2025, dépôts matures bien connus des participants, échantillon réduit, et constat que l’organisation présente aujourd’hui comme historique. Sa note du 24 février 2026 ajoute une difficulté de méthode. Dans une seconde campagne lancée en août 2025 avec un panel élargi, 30 à 50 % des développeurs ont indiqué renoncer à soumettre certaines tâches plutôt que de les traiter sans IA ; METR en déduit que son estimation est une borne inférieure. Sur cette cohorte recrutée pour l’occasion, l’effet mesuré est de −4 %, avec un intervalle de confiance allant de −15 % à +9 % : le signe lui-même n’est pas établi. Ni « 19 % plus lent » ni « deux fois plus vite » ne se transposent à votre équipe.

Suivez plutôt quatre indicateurs de livraison. Le délai de cycle situe le goulot, mais s’améliore aussi quand la revue est bâclée. Le taux de retour en revue révèle le coût transféré aux relecteurs. Le taux d’échec des changements et le délai de restauration mesurent la qualité livrée. Relevez-les quatre à six semaines avant le déploiement, introduisez l’outil sur un périmètre restreint, comparez à équipe constante, décidez sur la tendance et non sur un point. C’est la tension que DORA 2025 documente : une relation positive entre adoption de l’IA et débit de livraison, qui inverse le constat de l’édition 2024, et une relation négative avec la stabilité. Votre mesure sert à savoir de quel côté penche votre équipe.

Enfin, un score public ne prédit pas à lui seul le comportement sur votre dépôt. OpenAI a publié le 23 février 2026 une note expliquant pourquoi elle cesse d’évaluer SWE-bench Verified : contamination des données d’entraînement et cas de test défectueux peuvent rendre une progression ambiguë. Un benchmark public peut aider à présélectionner ou écarter un candidat, mais ne doit pas décider seul. Construisez le classement final sur dix à vingt tâches tirées de votre historique, rejouées à l’identique à chaque changement d’outil ou de modèle.

Ce que l’IA ne résout pas dans le développement logiciel

  • Elle ne remplace pas la spécification. Un agent exécute ce qui est écrit, pas ce qui était voulu. Là où l’exigence est floue, du code est produit plus vite autour d’un malentendu.
  • Elle ne compense pas une architecture illisible. Sur une base couplée et sans tests, le code localement correct aggrave le couplage.
  • Elle ne réduit pas la charge de revue, elle la déplace. Tant que la capacité de revue n’est pas renforcée, accélérer l’écriture allonge la file d’attente.
  • Elle ne garantit pas la sécurité. La justesse syntaxique progresse plus vite que la justesse sécuritaire, et les mesures publiques de Veracode ne montrent pas de rattrapage d’une vague à l’autre.
  • Elle ne fournit aucun gain chiffré généralisable. Les études portent sur des contextes précis, avec des intervalles de confiance larges, et se contredisent en partie. Seule votre propre mesure conclut pour votre équipe.

Checklist avant d’industrialiser l’assistance au code

  • ☐ Un fichier de règles projet (AGENTS.md ou équivalent) est versionné et relu en revue.
  • ☐ Une commande unique lance analyse statique, types et tests, en quelques minutes.
  • ☐ Les modules sans tests sont identifiés et interdits à la délégation autonome.
  • ☐ Le périmètre de fichiers modifiables est explicite pour toute tâche déléguée.
  • ☐ La détection de secrets tourne en pré-commit et en intégration continue.
  • ☐ L’ajout de dépendance par un agent exige une validation humaine.
  • ☐ Le réglage du filtre de correspondance avec le code public est documenté.
  • ☐ Le contrat exclut par écrit l’usage de votre code pour l’entraînement.
  • ☐ Les agents autonomes s’exécutent isolés, avec trafic sortant restreint, et n’approuvent jamais leur propre proposition de fusion.
  • ☐ Délai de cycle, retours en revue et taux d’échec sont relevés avant et après.

FAQ sur l’IA dans le développement logiciel

Quel assistant de code choisir en 2026 ?

Choisissez un niveau d’assistance avant un produit. Pour la complétion, la latence et le filtrage du code public priment ; pour un agent, les droits accordés et la portabilité de vos règles.

L’IA rend-elle les développeurs plus productifs ?

Les mesures ne concordent pas. DORA 2025 associe l’adoption à un débit accru et à une instabilité accrue. L’essai de METR mesurait en 2025 un ralentissement de 19 % sur un petit échantillon, et sa reprise de 2026 donne un effet non concluant. Seule une mesure locale, avant et après, permet de conclure.

Faut-il relire chaque ligne générée par une IA ?

Oui, avec une intensité proportionnelle au niveau d’assistance et à la criticité du code. Aux niveaux 3 et 4, relisez le diff complet et refusez tout changement que personne dans l’équipe ne peut expliquer.

Qu’est-ce que le slopsquatting ?

C’est l’enregistrement, sur un registre public, d’un nom de paquet inexistant qu’un modèle suggère régulièrement. Il exploite une erreur reproductible du modèle, non une faute de frappe. Parades : validation humaine de toute nouvelle dépendance, versions verrouillées, vérification de l’ancienneté du paquet.

Comment écrire un bon fichier AGENTS.md ?

Écrivez ce que le modèle ne peut pas déduire du code : commandes exactes de vérification, invariants métier, zones interdites, décisions déjà prises. Une page suffit. Supprimez tout ce qu’un analyseur statique impose déjà, et traitez le fichier comme du code : relu en revue, corrigé quand une règle est ignorée deux fois.

Le code généré par une IA est-il moins sécurisé ?

Les mesures publiques disponibles, notamment celles de Veracode en 2026, situent autour de la moitié la part des tâches où le code produit passe les contrôles de sécurité, sans consigne de sécurité explicite dans la demande. Ce n’est ni un verdict sur votre code, ni une raison d’exclure l’assistance : c’est un argument pour maintenir analyse statique, analyse des dépendances et revue humaine sur les zones sensibles.

Mon code est-il utilisé pour entraîner les modèles ?

Cela dépend de l’offre, du contrat, de la configuration et de leur version en vigueur. Certaines offres excluent l’entraînement sur les contenus clients ou proposent des contrôles de rétention, mais ne le supposez ni d’une étiquette « professionnelle » ni du prix. Vérifiez les conditions, le DPA et les réglages actuels, puis exigez les engagements nécessaires par écrit.

Un agent peut-il remplacer une revue de code humaine ?

Non. Il lit un diff, pas un système : il ignore l’intention initiale, les appelants externes et ce qui manque. Il fixe utilement l’ordre du jour de la revue humaine, il ne la remplace pas.

Pour aller plus loin

Sur Promptique : le guide des agents IA et de MCP pour la conception au-delà du code, et le guide de l’IA locale en 2026 pour l’auto-hébergement.

Sources externes :

Continuer

À lire ensuite