L’intelligence artificielle sait aujourd’hui compléter une fonction, proposer un test, expliquer une erreur et transformer une consigne en première version de code. Ces capacités sont assez concrètes pour modifier les habitudes d’une équipe. Elles ne suffisent pourtant pas à conclure que le métier de développeur va disparaître.

La question utile n’est pas de savoir si une machine peut écrire du code. Elle consiste à déterminer qui comprend le problème, choisit les compromis, vérifie le résultat et en assume les conséquences. Un logiciel n’est pas seulement une suite d’instructions : c’est une réponse durable à un besoin humain ou économique, placée dans un système technique et réglementaire réel.

Ce que l’IA change déjà dans la programmation

Les assistants de programmation accélèrent des tâches bien délimitées : produire une structure répétitive, retrouver une syntaxe, générer des données de test, résumer un module ou proposer plusieurs pistes de correction. Ils sont aussi utiles pour explorer une bibliothèque inconnue et réduire le temps passé sur des opérations mécaniques.

Cette assistance peut déplacer l’effort vers la formulation du problème et la vérification. Une équipe qui connaît son architecture et dispose de tests solides peut comparer rapidement une proposition à ses conventions. Un développeur débutant peut obtenir une explication immédiate, à condition de la confronter à la documentation et au comportement réel du programme.

Les résultats mesurés restent liés au contexte. Une étude contrôlée publiée avec le concours de GitHub a observé un gain sur une tâche de programmation circonscrite. Elle n’établit pas que le même effet se reproduit pour une migration complexe, un incident de production ou la conception d’un système complet. La productivité d’une suggestion locale et la qualité d’un produit sur plusieurs années sont deux mesures différentes.

Générer du code ne revient pas à construire un produit

Une demande métier arrive rarement sous la forme d’une spécification parfaite. « Simplifier les commandes » peut impliquer la gestion des stocks, des paiements, des droits d’accès, des annulations, de la fiscalité et des opérations hors connexion. Le travail commence par des questions : qui agit, dans quel ordre, avec quelles données et que doit-il se passer en cas d’échec ?

L’IA peut proposer une implémentation à partir du contexte fourni. Elle ne rencontre pas les utilisateurs, ne négocie pas les priorités et ne porte pas la connaissance tacite de l’organisation. Si le besoin est incomplet, la réponse peut être techniquement plausible tout en résolvant le mauvais problème.

Le développeur transforme donc une intention en règles vérifiables. Il relie les décisions produit, la conception de l’interface, le modèle de données, les contraintes opérationnelles et la capacité réelle de maintenance. Cette activité demeure centrale, même lorsque la saisie du code est fortement assistée.

L’architecture demande une vision d’ensemble

Une proposition générée peut fonctionner dans un fichier isolé et fragiliser le système complet. Elle peut contourner un mécanisme d’autorisation, dupliquer une règle métier ou créer une dépendance difficile à exploiter. La qualité d’une architecture tient moins à la sophistication qu’à la cohérence de ses frontières et de ses décisions.

Prenons un formulaire qui enregistre une demande commerciale et envoie une notification. L’ordre des opérations est essentiel : la demande doit être conservée même si l’email échoue. Il faut aussi éviter les doubles soumissions, valider les données côté serveur et limiter les abus. Générer la vue en quelques secondes ne remplace pas le raisonnement sur l’intégrité et les pannes partielles.

Un développeur expérimenté évalue aussi le coût futur. Une abstraction supplémentaire est-elle nécessaire ? Le système pourra-t-il être observé et restauré ? L’équipe comprendra-t-elle ce choix dans un an ? L’IA peut aider à comparer des options, mais la décision dépend du produit, des risques et des personnes qui l’exploiteront.

Sécurité : une responsabilité qui ne se délègue pas

Du code correct en apparence peut exposer une donnée, oublier un contrôle d’accès ou accepter une entrée dangereuse. Les recommandations du NIST sur le développement sécurisé inscrivent la sécurité dans tout le cycle de vie, avec des pratiques de préparation, de protection, de production et de réponse aux vulnérabilités. Elles ne réduisent pas la sécurité à une relecture finale.

Les outils génératifs ajoutent leurs propres risques : contexte sensible envoyé à un service, dépendance suggérée sans vérification, sortie interprétée comme une instruction fiable ou fausse assurance produite par une réponse fluide. La documentation de GitHub Copilot rappelle que les réponses peuvent être inexactes ou incomplètes et qu’elles doivent être relues et testées.

Le NIST recommande également une gestion explicite des risques propres à l’IA générative. Pour une équipe de développement, cela implique des règles simples : ne pas fournir de secrets, connaître les conditions de traitement des données, exécuter les contrôles automatiques, examiner les changements sensibles et conserver un responsable humain identifiable.

Maintenance : le code doit rester compréhensible

La majorité de la vie d’un logiciel se déroule après sa première livraison. Les dépendances évoluent, les usages réels révèlent des cas limites et de nouvelles personnes rejoignent l’équipe. Une solution rapidement générée devient une dette si personne ne peut expliquer ses hypothèses.

La maintenance demande de relier une anomalie à son contexte historique, d’évaluer l’impact d’une correction et de préserver les comportements attendus. L’IA peut résumer un ensemble de fichiers ou proposer un test de régression. Elle ne garantit pas que le résumé soit complet, ni que le test représente l’intention métier. L’historique, les journaux, les retours utilisateurs et la connaissance du domaine restent déterminants.

La bonne pratique consiste à traiter toute proposition comme une contribution à examiner : diff lisible, tests pertinents, vérification des erreurs, revue des permissions et documentation des décisions qui ne se déduisent pas du code.

Les compétences se déplacent, elles ne s’effacent pas

L’écriture manuelle de chaque ligne devient moins centrale pour certaines tâches. En parallèle, la capacité à décomposer un problème, lire du code, diagnostiquer un comportement et concevoir des tests gagne en valeur. Pour utiliser un assistant avec discernement, il faut reconnaître une réponse fragile et savoir revenir aux fondamentaux.

Les développeurs devront aussi mieux expliciter leurs décisions. Donner du contexte à un outil ressemble à une forme de spécification : contraintes, exemples, cas d’échec et critères d’acceptation. Une consigne vague produit souvent un résultat générique ; une demande précise exige déjà une compréhension approfondie.

Enfin, les compétences relationnelles restent décisives. Expliquer un risque à une direction, écouter un utilisateur, arbitrer avec un designer ou préparer une mise en production sont des activités collectives. Elles déterminent la qualité du produit autant que la vitesse de génération du code.

Un métier transformé plutôt que supprimé

Certaines tâches vont diminuer, d’autres vont apparaître et les rôles évolueront différemment selon les organisations. Les équipes capables d’intégrer l’IA à un processus solide pourront livrer plus vite sur des travaux adaptés. Celles qui utilisent la génération pour contourner l’analyse, les tests ou la revue risquent surtout d’accélérer la création de défauts.

Le développeur de demain écrira peut-être moins de code élémentaire. Il restera responsable de la pertinence du système, de sa sécurité, de sa maintenabilité et de son effet sur les utilisateurs. L’IA devient un outil puissant dans cette chaîne. Elle ne remplace ni le jugement, ni la responsabilité, ni la compréhension du réel.

Sources

La rédaction — Opus Stellar CI