Les erreurs que font les entreprises avec l'IA : produire plus vite ne suffit pas

"On dépense trop en tokens."

"Les équipes utilisent l'IA, mais on ne sait pas vraiment ce que ça apporte."

"Les développeurs vont plus vite, mais les leads passent leur temps à relire."

"Les specs sont plus longues, mais pas forcément plus claires."

"La QA reçoit plus de choses à tester."

"On a l'impression que tout va trop vite."

Ces phrases reviennent de plus en plus souvent dans les entreprises qui ont commencé à intégrer l'IA dans leurs usages quotidiens.

Elles ne prouvent pas que l'IA ne marche pas.

Elles montrent plutôt autre chose : beaucoup d'entreprises ont accéléré la production sans renforcer leur capacité à cadrer, relire, tester, sécuriser et mesurer.

C'est là que le sujet devient intéressant pour un CTO, un lead developer freelance ou un responsable technique externalisé.

L'enjeu n'est plus seulement de "mettre de l'IA" dans les outils. Il est de comprendre ce que l'IA modifie dans le système de travail.

Elle peut aider la direction à décider plus vite.
Elle peut aider le produit à mieux spécifier.
Elle peut aider la technique à accélérer certains développements.
Elle peut aider la QA à mieux explorer les cas limites.

Mais elle peut aussi déplacer la charge ailleurs.

Vers les leads.
Vers les reviewers.
Vers la QA.
Vers la sécurité.
Vers les équipes qui doivent corriger, expliquer, vérifier ou maintenir ce que l'IA a permis de produire plus vite.

La vraie question n'est donc pas :

Est-ce que l'IA nous fait produire plus ?

La bonne question est :

Est-ce que l'IA améliore notre capacité à décider, spécifier, développer, tester et livrer sans rendre le système plus fragile ?

L'IA est déjà utilisée, mais rarement maîtrisée

L'adoption de l'IA n'est plus marginale.

McKinsey indiquait dans son enquête 2025 que 88 % des organisations interrogées utilisaient régulièrement l'IA dans au moins une fonction. Mais l'impact financier reste beaucoup plus limité : seuls 39 % des répondants déclarent un impact sur l'EBIT à l'échelle de l'entreprise.¹

Côté développement logiciel, le rapport DORA 2025 de Google observe une adoption quasi généralisée : 90 % des répondants déclarent utiliser l'IA au travail, et plus de 80 % estiment qu'elle améliore leur productivité.²

Ces chiffres peuvent donner l'impression que le sujet est réglé.

Il ne l'est pas.

Dans la même enquête McKinsey, les entreprises les plus performantes se distinguent moins par le simple usage de l'IA que par leur capacité à redessiner les workflows, définir les responsabilités, suivre des indicateurs et préciser quand une validation humaine est nécessaire.¹

Autrement dit : l'IA crée rarement de la valeur durable lorsqu'elle est seulement ajoutée par-dessus l'existant.

Elle crée de la valeur quand l'entreprise repense la façon dont le travail circule.

C'est souvent là que les erreurs commencent.

Erreur 1 : Regarder le coût des tokens sans regarder ce qu'ils achètent

La première réaction d'une direction est souvent financière.

La facture monte.
Les outils se multiplient.
Les abonnements s'empilent.
Les appels API augmentent.
Les tokens deviennent une ligne visible.

La question arrive vite :

Est-ce que ça ne coûte pas trop cher ?

Mais cette question est incomplète.

Une dépense IA n'est pas excessive parce qu'elle est élevée. Elle devient excessive quand personne ne sait dire ce qu'elle améliore.

Une équipe peut dépenser 1 000 $ par développeur et par mois en tokens, licences ou outils IA. Ce n'est pas forcément absurde si cette dépense réduit fortement le cycle time, améliore la qualité des livrables, diminue le rework ou augmente la capacité de delivery.

À l'inverse, une dépense de 100 $ par mois peut être trop chère si elle génère surtout du bruit, des corrections, des PR plus longues ou une charge de review supplémentaire.

Le coût brut ne suffit pas.

Il faut suivre un coût par résultat.

Ce tableau change la discussion.

On ne parle plus seulement de dépense.

On parle de rendement opérationnel.

Checklist : avant de couper ou augmenter un budget IA

• Quel workflow l'IA améliore-t-elle ?
• Quel indicateur a bougé depuis son adoption ?
• Le gain est-il individuel ou visible sur toute la chaîne ?
• Le coût est-il suivi par équipe, par usage ou par résultat ?
• Les équipes gagnent-elles du temps, ou déplacent-elles la charge ailleurs ?
• Les incidents, bugs ou allers-retours ont-ils baissé ?
• Le coût augmente-t-il plus vite que la valeur mesurée ?

Si l'entreprise ne sait pas répondre à ces questions, le problème n'est pas forcément le coût de l'IA.

Le problème est l'absence de pilotage.

Erreur 2 : Confondre vitesse individuelle et performance collective

L'IA donne souvent une impression immédiate de vitesse.

Un développeur écrit plus vite.
Un Product Owner produit une spec plus vite.
Un commercial prépare une réponse plus vite.
Un support génère une synthèse plus vite.

Mais une entreprise ne livre pas grâce à une somme de vitesses individuelles.

Elle livre grâce à un système.

Entre une idée et une livraison, il y a du cadrage, de l'arbitrage, de la spécification, du développement, de la revue, des tests, du déploiement, du support et de la maintenance.

Si l'IA accélère une étape mais surcharge les suivantes, le gain peut disparaître.

C'est particulièrement vrai côté technique.

Un développeur peut produire plus vite du code avec un assistant. Mais si ce code augmente la taille des pull requests, demande plus de relecture, introduit des choix implicites ou ajoute des tests superficiels, le delivery global ne s'améliore pas forcément.

Il peut même ralentir.

Une étude METR menée en 2025 auprès de développeurs open source expérimentés a observé un résultat contre-intuitif : sur des projets qu'ils connaissaient bien, les participants ont pris 19 % de temps en plus lorsqu'ils étaient autorisés à utiliser des outils IA. Les développeurs pensaient pourtant avoir été accélérés.³

Ce résultat ne signifie pas que l'IA ralentit toujours les développeurs.

Il rappelle une chose importante : la productivité ressentie n'est pas une preuve de productivité réelle.

Le bon indicateur n'est pas :

Est-ce que chacun va plus vite ?

Le bon indicateur est :

Est-ce que le système livre mieux ?

Erreur 3 : Automatiser des processus flous

L'IA est très forte pour produire quelque chose à partir d'un contexte imparfait.

C'est aussi son danger.

Si une règle métier est floue, elle peut la reformuler proprement.
Si une spec est incomplète, elle peut lui donner une apparence structurée.
Si un processus est bancal, elle peut accélérer son exécution.
Si une documentation est obsolète, elle peut produire une réponse obsolète avec assurance.

L'IA ne remplace pas le cadrage.

Elle rend le mauvais cadrage plus rapide.

C'est souvent visible dans les équipes produit.

Une demande métier arrive :

On veut que les clients puissent gérer leurs préférences.

L'IA peut transformer cette phrase en user stories, critères d'acceptation, cas de test et parcours. C'est utile.

Mais elle ne sait pas forcément que certains clients ont plusieurs établissements, que les permissions varient selon les rôles, que l'export comptable dépend de cette préférence, ou que le support utilise déjà une règle différente dans le back-office.

Le résultat peut être très propre.

Et pourtant incomplet.

Décision à prendre avant d'automatiser

L'IA est utile quand elle aide à clarifier.

Elle devient risquée quand elle permet de sauter l'étape de clarification.

Erreur 4 : Produire plus de specs sans produire plus de clarté

Côté produit et fonctionnel, l'IA peut être un très bon outil.

Elle peut aider à explorer un problème, lister des cas limites, préparer un atelier, comparer plusieurs options ou transformer des notes en première version de spec.

Mais elle peut aussi créer un piège : la fausse complétude.

Une spec générée par IA peut être bien structurée, bien écrite, longue, agréable à lire.

Et pourtant mauvaise.

Mauvaise parce que les critères d'acceptation ne sont pas testables.
Mauvaise parce que les règles métier sensibles sont absentes.
Mauvaise parce que les impacts transverses ne sont pas traités.
Mauvaise parce que les cas limites sont génériques.
Mauvaise parce qu'elle répond à la solution demandée, pas au problème réel.

L'IA peut aider une équipe produit à être plus précise, plus proactive et plus complète.

Mais seulement si elle est utilisée comme un outil de questionnement, pas comme une machine à produire des tickets.

Ce qu'une bonne spec assistée par IA doit améliorer

Une bonne spec IA n'est pas une spec plus longue.

C'est une spec qui réduit les allers-retours.

Checklist produit avant passage en développement

• Le problème utilisateur est-il formulé avant la solution ?
• Les hypothèses sont-elles distinguées des faits ?
• Les règles métier sont-elles validées par une personne métier ?
• Les rôles et permissions sont-ils couverts ?
• Les cas limites sont-ils spécifiques au produit ?
• Les critères d'acceptation sont-ils testables ?
• Les impacts sur support, facturation, reporting ou API sont-ils vérifiés ?
• La QA peut-elle préparer ses tests sans deviner l'intention ?

Si la réponse est non, l'IA n'a pas encore terminé son travail.

Ou plutôt : l'équipe n'a pas encore terminé son cadrage.

Erreur 5 : Accélérer le code sans renforcer la revue

Côté développement, l'IA est déjà largement utilisée.

Elle aide à écrire du boilerplate, générer des tests, comprendre une API, expliquer du code legacy, produire un script ou proposer une implémentation.

Le gain peut être réel.

Mais un effet secondaire apparaît vite : le volume de code à relire augmente.

Ce n'est pas seulement une question de quantité.

C'est une question de charge cognitive.

Un code généré par IA peut être propre en surface. Il compile. Il suit à peu près le style attendu. Il a même des tests. Mais le reviewer doit vérifier autre chose :

• l'intention est-elle correcte ?
• la solution respecte-t-elle l'architecture ?
• les tests vérifient-ils vraiment le comportement ?
• une règle métier a-t-elle été inventée ?
• le code introduit-il une duplication ?
• une faille de sécurité est-elle cachée dans un flux plausible ?
• le développeur comprend-il ce qu'il soumet ?

Le rapport DORA 2025 montre que l'adoption de l'IA est très forte et que beaucoup de développeurs perçoivent un gain de productivité. Mais il souligne aussi la persistance d'un problème de confiance dans le code généré.²

Stack Overflow observe un signal similaire dans son Developer Survey 2025 : davantage de développeurs déclarent se méfier de l'exactitude des outils IA qu'ils ne déclarent leur faire confiance.⁴

Sonar parle même d'un goulot d'étranglement de vérification : selon son enquête, seuls 48 % des développeurs disent toujours vérifier leur code assisté par IA avant commit, alors même que beaucoup doutent de sa correction fonctionnelle.⁵

C'est un vrai sujet pour les leads.

L'IA peut créer une dette de vérification.

Le code arrive plus vite.
La responsabilité de comprendre reste humaine.

Indicateurs à suivre pour les leads et reviewers

La question n'est pas de savoir si les développeurs écrivent plus vite.

La question est de savoir si les leads peuvent encore garantir la cohérence du système.

Erreur 6 : Faire porter l'incertitude à la QA

La QA est souvent l'endroit où les ambiguïtés finissent.

Une spec floue arrive en test.
Un développement accéléré arrive en test.
Un cas limite oublié arrive en test.
Une règle métier implicite arrive en test.

Avec l'IA, ce phénomène peut augmenter.

Le produit génère plus de scénarios.
Les développeurs livrent plus vite.
Les tests automatisés sont générés plus facilement.
Les releases contiennent plus de modifications.

Sur le papier, c'est positif.

En pratique, la QA peut se retrouver à trier plus de bruit.

Plus de cas de test ne veut pas dire meilleure couverture.
Plus de tests automatisés ne veut pas dire meilleure fiabilité.
Plus de scénarios ne veut pas dire meilleure compréhension du risque.

La QA ne doit pas devenir le service qui absorbe l'incertitude générée en amont.

Elle doit être intégrée plus tôt.

Ce que l'IA doit améliorer côté QA

L'IA peut très bien aider la QA.

Elle peut proposer des cas limites, générer des jeux de données, résumer des tickets, préparer une matrice de risques ou analyser des logs.

Mais cette aide doit être évaluée.

Un plan de test généré en trente secondes n'a de valeur que s'il couvre des risques réels.

Erreur 7 : Penser que l'IA va automatiquement motiver les équipes

L'IA peut soulager les équipes.

Elle peut enlever des tâches répétitives, aider à démarrer, débloquer une recherche, expliquer un morceau de code, générer une première version ou réduire la charge mentale sur certaines activités.

Dans ces cas, elle est motivante.

Mais elle peut aussi produire l'effet inverse.

Une équipe peut perdre en motivation si elle a l'impression que :

• la vitesse compte plus que la qualité ;
• le jugement humain est moins reconnu ;
• les seniors deviennent des correcteurs permanents ;
• les juniors apprennent moins en profondeur ;
• les développeurs valident du code qu'ils comprennent mal ;
• la QA doit absorber plus d'incertitude ;
• le produit produit plus de documents mais tranche moins ;
• l'entreprise surveille l'usage IA plutôt que l'impact réel.

Le problème n'est pas que l'IA automatise.

Le problème apparaît quand les équipes deviennent opératrices d'un flux qu'elles ne maîtrisent plus.

Le travail change.

Les développeurs écrivent parfois moins de code à la main, mais doivent davantage relire, orienter, corriger et arbitrer. Les leads passent moins de temps à expliquer une syntaxe, mais plus de temps à protéger l'architecture. Les QA ne testent plus seulement des écrans, mais aussi des comportements générés ou accélérés par l'IA.

Ce changement doit être reconnu.

Sinon, l'entreprise croit avoir réduit la charge.

Les équipes, elles, sentent surtout qu'elle a changé de forme.

Signaux faibles de démotivation

• Les développeurs disent "je vais plus vite", mais semblent moins sûrs de leurs décisions.
• Les seniors relisent plus et conçoivent moins.
• Les juniors demandent moins d'explications parce qu'ils demandent d'abord à l'IA.
• La QA intervient tard et sous pression.
• Les équipes parlent moins d'apprentissage et plus de validation.
• Les débats techniques sont remplacés par "l'IA a proposé ça".
• Les revues deviennent plus longues mais moins pédagogiques.
• Le management valorise le volume produit plus que la qualité livrée.

Ces signaux ne veulent pas dire qu'il faut réduire l'usage de l'IA.

Ils veulent dire qu'il faut revoir l'organisation du travail autour de l'IA.

Erreur 8 : Acheter des outils avant de définir les usages

Beaucoup d'entreprises commencent par comparer les outils.

Quel modèle choisir ?
Quel copilote ?
Quel assistant ?
Quel agent ?
Quel abonnement ?
Quel fournisseur ?
Quel outil dans l'IDE ?
Quel connecteur avec le CRM ou la documentation ?

Ces questions sont utiles.

Mais elles arrivent souvent trop tôt.

Le mauvais ordre ressemble à ça :

outil → usage → métrique → justification

Le bon ordre devrait être :

problème → workflow → risque → mesure → outil

Avant de choisir une solution, il faut savoir ce qu'on veut améliorer.

Tableau de décision avant choix d'outil IA

Gartner a d'ailleurs prédit que plus de 40 % des projets d'IA agentique seraient annulés d'ici fin 2027, notamment à cause des coûts, d'une valeur métier floue ou de contrôles de risques insuffisants.⁶

Ce n'est pas un argument contre les agents.

C'est un argument contre les agents mal cadrés.

Un agent utile n'est pas un chatbot avec plus de droits.

C'est un composant applicatif avec un objectif, des permissions, des limites, des logs, des tests et un mode de reprise.

Erreur 9 : Ne pas suivre les signaux faibles

Les dashboards arrivent souvent trop tard.

Les équipes, elles, sentent les problèmes avant qu'ils deviennent visibles dans les métriques.

Il faut donc écouter les signaux faibles.

Ces signaux sont précieux.

Ils évitent de piloter uniquement par la facture ou par l'adoption.

Une entreprise peut avoir beaucoup d'utilisateurs IA et peu d'impact réel.

Elle peut aussi avoir un usage plus limité, mais très rentable, parce qu'il cible un point de friction précis.

Erreur 10 : Traiter la sécurité et la conformité comme des sujets de fin de projet

Tant que l'IA sert à reformuler un texte interne, le risque reste limité.

Mais dès qu'elle touche aux données, aux clients, au code, aux décisions ou aux actions automatisées, le sujet change.

Un assistant qui lit une documentation interne n'a pas le même risque qu'un agent capable d'écrire dans un CRM, créer un ticket, modifier une commande ou envoyer une réponse client.

L'OWASP classe plusieurs risques propres aux applications LLM, dont le prompt injection, la divulgation d'informations sensibles, la mauvaise gestion des sorties et l'excès d'autonomie donné aux agents.⁷

Le NIST propose aussi un profil dédié à l'IA générative dans son AI Risk Management Framework, pour aider les organisations à identifier les risques spécifiques et les actions de maîtrise adaptées.⁸

En Europe, le cadre réglementaire continue de se préciser. L'AI Act est entré en vigueur en août 2024, avec une application progressive : les pratiques interdites et obligations de littératie IA s'appliquent depuis février 2025, les obligations relatives aux modèles d'IA à usage général depuis août 2025, et d'autres obligations suivent selon les catégories de systèmes.⁹

La CNIL rappelle aussi que lorsqu'un système d'IA utilise des données personnelles, le RGPD peut s'appliquer, avec un objectif à définir clairement et une limitation des données utilisées.¹⁰

Pour une PME produit ou un éditeur logiciel, cela ne veut pas dire transformer chaque usage IA en programme juridique lourd.

Mais il faut traiter les questions tôt.

Checklist sécurité et conformité

• L'usage manipule-t-il des données personnelles ?
• L'usage expose-t-il du code source ou des secrets ?
• Le fournisseur conserve-t-il les données ?
• Les données peuvent-elles être utilisées pour entraîner un modèle ?
• L'utilisateur sait-il qu'il interagit avec une IA ?
• Les sorties sont-elles journalisées ?
• Peut-on expliquer ou retrouver une décision ?
• L'agent peut-il agir dans un outil interne ?
• Les droits de l'agent sont-ils limités ?
• Existe-t-il un mode de désactivation ?
• Les erreurs sont-elles détectables et récupérables ?

Le modèle ne doit pas être une zone de confiance.

Il doit être traité comme un composant faillible.

Comment reprendre le contrôle sans bloquer l'IA

Le but n'est pas de ralentir les équipes.

Le but est d'éviter que l'IA accélère uniquement la production visible, tout en cachant les coûts dans la revue, la QA, la sécurité ou la maintenance.

Une démarche saine peut tenir en six étapes.

1. Cartographier les usages réels

Les usages existent déjà.

Il faut les regarder sans posture punitive :

• quels outils sont utilisés ?
• par quelles équipes ?
• pour quelles tâches ?
• avec quelles données ?
• avec quel niveau de risque ?
• avec quel gain perçu ?
• avec quels problèmes déjà observés ?

Cette cartographie révèle souvent des besoins très concrets.

Les équipes n'utilisent pas l'IA par hasard. Elles l'utilisent là où le système actuel est lent, pénible ou mal outillé.

2. Classer les usages par valeur et risque

Tous les usages IA ne méritent pas le même niveau de contrôle.

Ce classement évite deux erreurs.

Tout bloquer par peur.
Tout autoriser par enthousiasme.

3. Définir les métriques avant le déploiement

Avant de généraliser un usage, il faut mesurer l'état initial.

Sans baseline, l'entreprise pilotera à l'impression.

Et l'impression est souvent trompeuse avec l'IA.

4. Protéger les goulots d'étranglement

Il faut regarder où la charge va se déplacer.

Si les devs produisent plus vite, les leads doivent-ils relire plus ?
Si le produit spécifie plus vite, la QA doit-elle clarifier plus ?
Si le support répond plus vite, quelqu'un doit-il corriger plus souvent ?
Si un agent agit plus vite, qui surveille les erreurs ?

Chaque usage IA devrait répondre à cette question :

Quelle équipe risque d'absorber la charge cachée ?

C'est souvent là que se joue la réussite.

5. Mettre à jour les règles de delivery

L'IA doit entrer dans les standards de travail.

Par exemple :

• PR plus petites ;
• intention technique explicitée ;
• code généré compris par l'auteur ;
• tests relus, pas seulement générés ;
• prompts ou agents critiques versionnés ;
• sorties IA sensibles validées ;
• cas limites ajoutés aux critères d'acceptation ;
• usage IA mentionné quand il impacte une décision ;
• logs et coûts suivis pour les usages en production.

Ce n'est pas une bureaucratie.

C'est une manière de garder la maîtrise.

6. Faire des bilans courts et réguliers

Un usage IA doit être réévalué.

Les modèles changent.
Les coûts changent.
Les pratiques changent.
Les équipes apprennent.
Les risques évoluent.

Un bilan utile tient en quelques questions :

• Qu'est-ce qui a vraiment gagné du temps ?
• Où la charge s'est-elle déplacée ?
• Quels coûts ont augmenté ?
• Quels indicateurs se sont améliorés ?
• Quels incidents ou irritants sont apparus ?
• Qu'est-ce qu'on arrête ?
• Qu'est-ce qu'on généralise ?
• Qu'est-ce qu'on encadre davantage ?

L'entreprise doit pouvoir arrêter un usage IA qui n'apporte rien.

Elle doit aussi pouvoir investir davantage dans un usage coûteux mais très rentable.

Ce que le CTO doit surveiller

Le rôle du CTO n'est pas de dire oui ou non à l'IA.

Il est de protéger la capacité de l'entreprise à livrer durablement.

Il doit surveiller plusieurs équilibres.

C'est une posture d'équilibre.

Ne pas freiner par principe.
Ne pas accélérer par réflexe.

L'IA peut être un très bon levier de performance. Mais elle doit augmenter la capacité du système, pas seulement son débit apparent.

Conclusion : le problème n'est pas que l'IA coûte cher

Beaucoup d'entreprises se posent aujourd'hui la mauvaise question.

Elles demandent :

Est-ce que l'IA coûte trop cher ?

La vraie question est :

Est-ce que ce coût achète une amélioration réelle de notre système de travail ?

Si l'IA permet de décider plus vite, mieux spécifier, réduire les allers-retours, accélérer le delivery, améliorer la QA, diminuer les incidents ou mieux servir les clients, elle peut justifier un budget important.

Même très important.

Mais si elle augmente seulement le volume de production, la taille des PR, le bruit documentaire, la charge de review, les ambiguïtés en QA et les coûts API, alors elle n'a pas accéléré l'entreprise.

Elle a accéléré ses problèmes.

La maturité IA ne se mesure pas au nombre d'outils déployés.

Elle se mesure à la capacité de l'entreprise à absorber la vitesse qu'elle crée.

Mieux décider.
Mieux cadrer.
Mieux relire.
Mieux tester.
Mieux sécuriser.
Mieux mesurer.

C'est moins spectaculaire qu'une démo d'agent autonome.

Mais c'est ce qui fait la différence entre une expérimentation coûteuse et un vrai levier de delivery, de qualité et de business.

Votre entreprise utilise déjà l'IA, mais le pilotage reste flou ?

Coût des tokens, qualité du code généré, charge de review, impact sur la QA, gains réels sur le delivery : ces sujets méritent mieux qu'un ressenti.

Je vous aide à poser un cadre simple pour mesurer, sécuriser et améliorer vos usages IA sans freiner les équipes.

Planifier un échange

Sources

Footnotes

1. McKinsey, The State of AI: Global Survey 2025. L'enquête indique que 88 % des organisations interrogées utilisent l'IA dans au moins une fonction, mais que seuls 39 % des répondants constatent un impact EBIT à l'échelle de l'entreprise. Elle souligne aussi l'importance de la refonte des workflows, du leadership et des pratiques de validation humaine. ↩ ↩²

2. Google Cloud / DORA, State of AI-assisted Software Development 2025 et annonce Google Cloud associée. Le rapport indique notamment que 90 % des répondants utilisent l'IA au travail et que plus de 80 % estiment qu'elle améliore leur productivité, tout en soulignant les enjeux de confiance et d'intégration dans le système de delivery. ↩ ↩²

3. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Étude randomisée menée auprès de développeurs open source expérimentés, observant un ralentissement de 19 % dans son contexte expérimental malgré une perception inverse des participants. ↩

4. Stack Overflow, Developer Survey 2025. Le sondage indique que davantage de développeurs déclarent se méfier de l'exactitude des outils IA qu'ils ne déclarent leur faire confiance. ↩

5. Sonar, The AI trust gap: Why code verification matters et State of Code Developer Survey. Sonar met en avant un écart entre faible confiance dans le code généré et vérification effective, avec 48 % des développeurs déclarant toujours vérifier leur code assisté par IA avant commit. ↩

6. Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027. Gartner cite notamment les coûts, la valeur métier floue et des contrôles de risques insuffisants. ↩

7. OWASP, Top 10 for Large Language Model Applications. Le projet recense les principaux risques de sécurité des applications LLM, dont prompt injection, information disclosure, insecure output handling et excessive agency. ↩

8. NIST, AI Risk Management Framework: Generative Artificial Intelligence Profile. Le profil NIST-AI-600-1 aide les organisations à identifier les risques spécifiques de l'IA générative et à définir des actions de gestion adaptées. ↩

9. Commission européenne, AI Act : Shaping Europe's digital future. La Commission précise notamment l'approche par les risques, le calendrier d'application progressif et les obligations liées aux modèles d'IA à usage général. ↩

10. CNIL, AI system development: CNIL's recommendations to comply with the GDPR. La CNIL rappelle notamment qu'un système IA fondé sur des données personnelles doit avoir un objectif défini, explicite et légitime, et limiter les données traitées. ↩