🚀 Coder avec une IA : LLM & code pro (2026)
Découvrez pourquoi coder avec une IA (LLM en programmation) peut nuire ou booster la qualité : cognition, maintenance, données. Décidez sans suivre la tendance.
Pourquoi choisir de coder sans LLM dans son travail
Les assistants de programmation basés sur de grands modèles de langage promettent d'accélérer l'écriture, de proposer des tests et de débloquer quand on est coincé. Pourtant, une question revient rarement au centre des discussions : à quelles conditions leur aide vaut-elle vraiment le prix qu'elle fait payer à l'équipe, au code et à la capacité de jugement de ceux qui maintiennent ensuite ?
Refuser ces outils dans un contexte professionnel n'est pas forcément une posture technophobe. On peut comprendre l'apprentissage automatique, reconnaître ce que les modèles savent faire... et décider que leur usage quotidien ne convient pas à son environnement. Les raisons peuvent être cognitives, techniques, économiques, juridiques ou environnementales. Elles ne pèsent pas de la même façon partout, et elles ne mènent pas toujours à la même décision.
Cet article passe en revue les arbitrages concrets : l'effort mental, la qualité réelle du code produit, la maintenabilité, la dépendance à un service tiers, et les situations où un LLM peut quand même rendre service. L'objectif n'est pas de dire « utilisez l'IA » ou « rejetez-la », mais de proposer une méthode pour décider sans confondre adoption, compétence et obligation.
Pourquoi un développeur peut-il refuser les LLM sans être technophobe ?
Le débat est souvent réduit à une opposition caricaturale : les développeurs « modernes » utilisent l'IA, les autres refusent parce qu'ils seraient réfractaires au progrès. En pratique, c'est beaucoup plus nuancé. On peut avoir déjà fait de l'apprentissage automatique en production, testé des modèles locaux, suivi l'évolution des outils... et décider quand même de ne pas confier son travail quotidien à un assistant conversationnel.
La question n'est pas de savoir si les LLM sont intéressants. Ils le sont : ils produisent du texte cohérent, proposent des pistes et synthétisent des informations. La vraie question, c'est de savoir, pour une tâche donnée, si le gain qu'on obtient dépasse le temps et le coût de la vérification, de la sécurité, de la dépendance et de la compréhension du résultat.
Un LLM est aussi un service, pas seulement un outil
Un éditeur de code installé sur une machine reste généralement dans un cadre maîtrisé par l'équipe. À l'inverse, un assistant hébergé dans le cloud implique un service opéré par un fournisseur : règles, tarifs, limites, et conditions de traitement des données. Même quand l'offre parle de garanties, il faut regarder ce qui est réellement couvert : conservation, entraînement, journalisation, localisation et accès aux données.
Ce détail change la nature du choix. On ne choisit pas seulement « une fonctionnalité », on choisit une relation de dépendance avec un prestataire. Pour une expérimentation sur un dépôt public, le risque peut rester limité. Pour du code client, des secrets d'infrastructure, ou des données liées à une activité réglementée, il faut examiner le cadre avant de recopier quoi que ce soit dans une interface externe.
La compétence ne se mesure pas à l'adoption
Maîtriser un outil, c'est aussi savoir quand ne pas l'utiliser. Un développeur peut estimer qu'une modification de schéma, une migration courte ou une fonction déjà présente dans le projet sont plus simples qu'une réécriture proposée par un modèle. Ce jugement s'appuie sur la connaissance du système, de son historique et de ses contraintes - pas sur le nombre de lignes produites.
Refuser un LLM peut donc être une décision d'ingénierie, au même titre que choisir une bibliothèque éprouvée plutôt que de rajouter une dépendance. Et cette décision doit pouvoir évoluer : un refus « par principe » prive l'équipe d'usages utiles, tandis qu'une adoption automatique l'expose à des coûts qu'elle n'a pas évalués.
Les LLM réduisent-ils réellement l'effort de programmation ?
La promesse de productivité attire, parce qu'on voit vite le résultat : du code apparaît en quelques secondes. Mais la vitesse de génération n'est pas la vitesse de livraison. Il faut ajouter le temps pour comprendre la proposition, vérifier ce qu'elle suppose, l'adapter au code existant et corriger ce qui est faux. Sur une tâche bien cadrée, le bilan peut être positif. Sur un problème mal défini ou très dépendant du contexte, le temps gagné au départ revient souvent en relecture et en débogage.
Il y a aussi un coût moins visible : l'effort cognitif. Des enquêtes et travaux de recherche - par exemple une enquête de Microsoft sur des travailleurs du savoir et une étude sur l'écriture assistée - se sont intéressés aux effets de ces assistants sur la charge mentale et la confiance. Ces résultats ne prouvent pas que tous les développeurs « perdent » leurs capacités en utilisant un LLM. Ils invitent surtout à distinguer l'aide ponctuelle d'une délégation répétée du raisonnement.
La programmation, c'est aussi comprendre
Écrire du code, ce n'est pas seulement « mettre une solution au bon format ». En parcourant les données, en choisissant où poser une responsabilité, en observant les effets d'une modification, le développeur construit (ou ajuste) sa compréhension du système. Ces petits ajustements sont difficiles à mesurer avec un tableau de productivité, mais ils comptent quand le comportement réel diverge de la demande initiale.
Quand le modèle propose une solution tout de suite, il peut réduire le temps face à une page blanche. Il peut aussi raccourcir l'exploration nécessaire. Le risque ne tient pas au fait que « l'outil pense à la place » le jour même. Le vrai risque, c'est que des décisions locales soient acceptées sans que leur auteur ait construit une compréhension suffisante pour les expliquer - et pour les modifier ensuite.
Mesurer le coût complet, pas seulement les lignes générées
Pour juger un usage, comparez des tâches similaires et regardez plusieurs indicateurs : délai jusqu'à une modification validée, temps de revue, défauts après intégration, et effort pour reprendre le code ensuite. Une génération rapide qui déclenche plus de retours en revue n'est pas forcément un gain. À l'inverse, un assistant qui aide à formuler une piste ou à écrire un test répétitif peut réellement réduire le temps total.
Un test simple consiste à demander au développeur de reformuler le comportement du code généré sans rouvrir le modèle. S'il ne peut pas expliquer ses hypothèses, ses limites et ses effets sur les autres composants, l'équipe a peut-être gagné du temps... tout en abîmant sa capacité à maintenir le résultat.
Le code généré par IA est-il plus difficile à maintenir ?
Un code qui « a l'air propre » n'est pas automatiquement utile pour le produit. Les LLM ont tendance à fournir des réponses développées : commentaires, abstractions et tests qui donnent une impression de complétude. Mais le volume n'est pas une mesure de qualité. Une solution peut passer les tests proposés et rester inutilement complexe, décalée par rapport aux conventions du projet, ou basée sur une lecture incorrecte du besoin.
Dans une application existante, le problème n'est pas toujours l'erreur spectaculaire. Souvent, c'est le choix du niveau : au lieu de résoudre le problème de manière simple, un assistant peut créer un mécanisme « nouveau » alors qu'une contrainte de schéma ou une migration suffirait. Il peut aussi ajouter une couche d'abstraction alors que le projet suit déjà un motif plus direct. Isolément, ces décisions se défendent. Ensemble, elles augmentent le nombre de concepts à maîtriser pour chaque évolution.
Les tests ne valident pas automatiquement la bonne solution
Des tests générés en même temps que le code peuvent aider, notamment pour couvrir des cas oubliés. Mais s'ils reprennent les mêmes hypothèses erronées que l'implémentation, ils ne signaleront pas le problème. Un gros paquet de tests peut donc donner une fausse impression de couverture.
La revue doit porter sur les invariants du système : quelles données peuvent changer, quelles erreurs doivent être renvoyées, quelles règles métier ne doivent jamais être violées. Et il faut vérifier que les tests décrivent le comportement attendu - pas seulement la manière dont le modèle a choisi de l'implémenter.
La responsabilité de maintenance reste humaine
Le modèle ne sera pas là le jour de l'incident en production, de la migration suivante, ou du changement d'équipe. L'équipe, elle, devra expliquer le code, gérer ses effets et le faire évoluer. Quand personne ne comprend pourquoi une solution a été choisie, le bénéfice initial devient vite une dette de compréhension.
Avant d'intégrer une contribution assistée, il vaut la peine de se poser ces questions :
- Le changement est-il plus simple que ce qui existe déjà dans le projet ?
- Un développeur de l'équipe peut-il expliquer chaque décision importante ?
- Les tests valident-ils le besoin métier, ou seulement le code produit ?
- La solution respecte-t-elle les conventions et l'architecture existantes ?
- Son coût de maintenance serait-il acceptable si ce motif se répétait cent fois ?
La dernière question est celle qui tranche souvent. Une expérimentation isolée passe. C'est la répétition d'un motif coûteux qui finit par peser sur l'ensemble du produit.
Quels sont les coûts cachés des assistants de programmation ?
Le coût d'un assistant ne se limite pas à l'abonnement. Il faut compter le temps de contrôle, les changements de processus, l'exposition de données et la dépendance à un service dont les prix et les fonctionnalités peuvent évoluer. À cela s'ajoutent des questions environnementales et de gouvernance, qui varient selon la taille de l'organisation et la sensibilité de ses activités.
Données, RGPD et dépendance fournisseur
Dans l'Union européenne, l'utilisation d'un service d'IA doit être évaluée en fonction des données effectivement transmises et de la répartition des rôles entre acteurs. Le RGPD ne se résume pas à choisir une région d'hébergement : il faut comprendre les finalités du traitement, les accès, les durées de conservation et les engagements contractuels. Le CLOUD Act peut aussi poser problème pour des entreprises dont le fournisseur relève de la juridiction américaine. La localisation européenne ne suffit donc pas, à elle seule, à répondre à toutes les questions de juridiction.
Dans les faits, la règle opérationnelle doit être claire : aucun secret, donnée personnelle, extrait client ou code sensible ne doit partir vers un service non approuvé. Cette règle doit s'accompagner d'une liste d'outils autorisés et d'une procédure de validation. Sans ça, l'équipe finit souvent par s'en remettre aux habitudes de chacun.
Environnement et coût à l'échelle
Les infrastructures de calcul consomment de l'électricité et mobilisent des ressources matérielles. L'impact exact dépend du modèle, du centre de données, de la source d'énergie et du volume d'utilisation. Dans ces conditions, il est difficile de défendre une mesure « universelle » par requête sans contexte. En revanche, si une organisation multiplie les usages, elle doit intégrer la consommation et les besoins d'infrastructure dans son évaluation - comme elle le ferait pour un coût logiciel.
Un essai gratuit ou subventionné ne garantit pas un coût durable. Si l'assistant devient central dans le cycle de développement, regardez ce qui se passe quand le prix augmente, quand les quotas changent ou quand l'accès s'interrompt. Prévoir un plan de repli et conserver des compétences en interne réduit le risque de verrouillage.
Le coût humain de la mesure
Certaines équipes évaluent l'IA en comptant les suggestions acceptées ou le volume de code généré. Ces métriques sont simples à collecter, mais elles décrivent mal la valeur réellement livrée. Pire : elles peuvent pousser à utiliser l'outil sur des tâches où il ne sert à rien. Un indicateur utile doit rester lié au résultat : délai de livraison, défauts, temps de revue, satisfaction de l'équipe et capacité à maintenir le code.
Le bon calcul, c'est un coût total d'usage, pas une comparaison « prix d'abonnement » versus « zéro ». Il inclut le service, la gouvernance, le contrôle humain, les incidents possibles et le coût futur de la dépendance.
Comment décider si un LLM a sa place dans une équipe ?
Une politique utile évite deux réflexes : imposer l'IA à tout le monde au nom de la productivité, ou l'interdire sans distinction selon les usages. Le niveau de décision dépend du type de tâche, de la sensibilité des données et de la capacité de l'équipe à vérifier le résultat. Un assistant peut aider à débloquer une réflexion, sans devenir l'auteur de changements qu'on ne saurait pas contrôler.
Classer les tâches avant de choisir l'outil
Commencez par examiner chaque cas selon trois axes : sensibilité, vérifiabilité et coût de l'erreur. Reformuler un message technique, sans données confidentielles, se vérifie facilement. Modifier des éléments liés aux paiements, à l'authentification ou aux migrations de données a un coût d'erreur bien plus élevé et nécessite une revue renforcée.
Ensuite, vous pouvez définir trois niveaux :
- Usage autorisé : tâches à faible risque, données publiques ou synthétiques, résultat facile à vérifier.
- Usage encadré : assistance sur le code, via un outil approuvé, règles de données et revue humaine obligatoire.
- Usage interdit ou soumis à validation : secrets, données personnelles, code sensible, ou toute décision difficile à tester.
La classification doit refléter le métier. Une jeune équipe produit et un opérateur d'infrastructure critique n'ont pas le même profil de risque ni les mêmes obligations.
Tester un usage, pas « vendre » une transformation
Choisissez une tâche récurrente et limitée, fixez une période d'essai et comparez le processus avec la méthode habituelle. Mesurez le temps total, les corrections, les retours de revue et la compréhension du code. Gardez aussi une solution sans IA pendant la phase de test, pour ne pas confondre amélioration de l'outil et amélioration de l'organisation.
Le test doit prévoir une condition d'arrêt. Par exemple : si le temps de revue augmente durablement, si les données ne peuvent pas être suffisamment protégées, ou si l'équipe a du mal à expliquer les changements, alors l'usage est révisé. Une expérimentation sans critère de sortie finit souvent en adoption par inertie.
Accepter les usages utiles sans en faire une obligation
Un LLM peut aider à clarifier une erreur obscure, proposer un plan de diagnostic, ou générer un exemple minimal que le développeur vérifiera. Ce sont des usages ponctuels, très différents d'une délégation complète de la conception et de l'implémentation. La vraie différence ne tient pas au fait que le code soit écrit à la main ou généré ; elle tient à la capacité de l'équipe à comprendre ce qui a été produit et à l'assumer quand il faut le modifier.
À retenir : autorisez l'usage quand le bénéfice est mesurable, la donnée maîtrisée et la vérification réaliste. Gardez une voie sans IA, documentez les limites et ne transformez pas l'outil en preuve de compétence. La technologie restera là ; cela ne veut pas dire qu'elle doit s'imposer partout.
Conclusion : choisir l'outil, pas suivre l'injonction
Les LLM peuvent accélérer certaines tâches, mais la génération rapide n'est qu'une partie du coût réel. Il faut aussi compter le temps de vérification, la qualité du code dans son contexte, la capacité de l'équipe à maintenir ce code, les données exposées et la dépendance au fournisseur. Selon les cas, on adopte, on limite ou on s'en passe.
La décision la plus solide n'est ni l'enthousiasme automatique, ni le rejet « par principe ». C'est une politique claire, testée sur des tâches concrètes, avec des critères de réussite et la possibilité de faire marche arrière. Si un développeur préfère écrire son code lui-même parce qu'il comprend mieux le système, ce choix mérite d'être respecté. Un outil utile reste un choix ; il ne devrait pas devenir une injonction.