L’arrivée des assistants de programmation a créé une opposition séduisante : d’un côté les développeurs « authentiques », qui travailleraient sans intelligence artificielle ; de l’autre ceux qui délégueraient leur métier à un outil. Cette opposition décrit mal la réalité.

Un bon développeur ne se définit pas par la présence ou l’absence d’un assistant dans son éditeur. Il se reconnaît à sa capacité à comprendre un besoin, produire un système fiable, expliquer ses choix et répondre de ce qu’il livre. L’IA change les moyens disponibles ; elle ne supprime pas ces obligations.

Les fondamentaux restent le point de départ

Comprendre les types, les structures de données, les flux asynchrones, les requêtes, le réseau et les droits d’accès permet de raisonner lorsque le résultat ne correspond pas à l’attente. Sans ces bases, une suggestion convaincante peut être acceptée pour de mauvaises raisons.

Les fondamentaux ne se limitent pas à mémoriser une syntaxe. Ils donnent des modèles mentaux. Quand une page est lente, le développeur doit distinguer un problème de rendu, une requête trop large, une ressource lourde ou un service distant instable. Un assistant peut dresser une liste d’hypothèses ; l’ingénieur construit la mesure qui permet de les départager.

Cette maîtrise rend aussi l’utilisation de l’IA plus efficace. La personne qui sait ce qu’elle cherche fournit un contexte pertinent, impose des contraintes et repère rapidement une réponse hors sujet. L’outil amplifie alors une compétence existante au lieu de masquer une lacune.

Utiliser un outil n’est pas abandonner son jugement

Les développeurs ont toujours utilisé des abstractions : compilateurs, frameworks, bibliothèques, moteurs de recherche et analyseurs statiques. Personne n’exige de réécrire une base de données pour prouver sa valeur. La question est plutôt de savoir si l’outil est adapté, compris et contrôlé.

Un assistant peut aider à rédiger un premier test, comparer deux API, expliquer un message d’erreur ou préparer une transformation répétitive. Dans ces usages, il réduit une friction. Le développeur reste celui qui sélectionne la solution et la replace dans le contexte du projet.

La documentation de GitHub sur l’usage responsable de Copilot insiste sur la revue et la validation des réponses. Cette recommandation est valable au-delà d’un produit particulier : une sortie générée est une proposition probabiliste, pas une preuve de correction.

La compréhension du code généré est non négociable

Avant de conserver un changement, le développeur doit pouvoir répondre à quelques questions simples : quel comportement est ajouté ? Quelles entrées sont acceptées ? Que se passe-t-il en cas d’échec ? Quelles données sont lues ou modifiées ? Quel test échouerait si la logique était cassée ?

Si ces réponses restent floues, le code n’est pas prêt à rejoindre le produit. Le relire ligne par ligne ne suffit pas toujours. Il faut aussi vérifier sa place dans le système : conventions, permissions, concurrence, observabilité, dépendances et compatibilité.

Imaginons une fonction générée pour modifier le statut d’une commande. Elle peut réussir dans le cas nominal tout en autorisant un utilisateur à modifier la commande d’un autre client. Le problème n’est pas syntaxique. Il concerne l’autorisation sur l’objet, une règle que le contexte fourni à l’outil pouvait ne pas contenir.

La dépendance apparaît quand on ne sait plus avancer sans suggestion

Une utilisation intensive peut ralentir l’apprentissage si chaque difficulté est immédiatement transférée à l’assistant. Le risque n’est pas propre à l’IA : copier du code sans le comprendre produit le même effet. La fluidité de la réponse rend simplement ce réflexe plus facile.

Pour préserver son autonomie, le développeur peut alterner les modes de travail. Sur un sujet nouveau, il commence par formuler sa propre hypothèse. Il consulte la documentation officielle, écrit un exemple minimal, puis demande éventuellement une critique. Après génération, il reformule la solution et la reproduit sans dépendre du fil de conversation.

Les équipes peuvent aussi réserver des temps d’apprentissage sans assistance, notamment pour les fondamentaux, les entretiens de code et les exercices de diagnostic. L’objectif n’est pas d’interdire l’outil, mais d’empêcher que la compétence d’analyse se réduise.

Productivité : mesurer le résultat complet

Le nombre de lignes produites ou la vitesse d’un premier jet sont des indicateurs insuffisants. Une modification n’a de valeur que lorsqu’elle répond au besoin, passe les contrôles, peut être relue et ne crée pas une charge disproportionnée de maintenance.

Le rapport DORA 2025 présente l’IA comme un amplificateur dont les effets dépendent des capacités de l’organisation. Cette lecture est utile : dans une équipe avec des retours rapides, une documentation accessible et des tests fiables, l’assistance peut accélérer la boucle. Dans un environnement confus, elle peut produire plus vite davantage de changements difficiles à valider.

Une mesure raisonnable observe donc le délai jusqu’à une modification sûre, le taux de reprise, les défauts détectés et la facilité de revue. Elle distingue aussi les tâches. Générer une structure répétitive et décider d’une migration de données ne portent pas le même risque.

Les tests ne servent pas à confirmer aveuglément la réponse

Demander à la même conversation de produire le code et tous ses tests peut reproduire les mêmes hypothèses manquantes. Les tests doivent dériver du contrat attendu : cas nominal, limites, erreurs, permissions et effets persistants.

Un bon usage de l’IA consiste à solliciter des contre-exemples ou des scénarios oubliés, puis à les évaluer. L’outil peut suggérer un test pour une chaîne vide ; l’équipe doit savoir si le vrai risque est plutôt une double soumission, un accès concurrent ou une donnée appartenant à un autre utilisateur.

Les contrôles automatiques ne remplacent pas non plus la revue. Un test peut passer tout en validant le mauvais comportement. La combinaison la plus robuste associe spécification claire, tests indépendants, analyse statique, revue humaine et observation du logiciel en fonctionnement.

La responsabilité reste humaine

Quand un logiciel facture deux fois, expose une donnée ou bloque une activité, expliquer que le code venait d’un assistant ne résout rien. Le professionnel et l’organisation restent responsables de leurs choix, de leurs contrôles et de leurs procédures.

Le code d’éthique de l’ACM demande aux professionnels de l’informatique de considérer les effets de leur travail et de soutenir l’intérêt général. Ce principe s’applique quel que soit l’outil utilisé. Il invite à protéger la vie privée, éviter les dommages et être transparent sur les limites d’un système.

Cette responsabilité impose aussi de respecter les règles de l’entreprise : confidentialité des dépôts, licences, données autorisées dans les invites et validation des dépendances. Un outil utile dans un projet public peut être inadapté à un environnement contenant des informations sensibles.

Une pratique mature plutôt qu’un camp

Le refus systématique de l’IA peut priver une équipe d’un outil utile. Son adoption sans règles peut affaiblir la qualité et l’apprentissage. Une position professionnelle se construit entre ces extrêmes.

Elle commence par définir les usages acceptables et ceux qui exigent une revue renforcée. Elle conserve des chemins de travail sans assistant. Elle rend visibles les changements, protège les données et mesure les effets réels. Surtout, elle donne au développeur le droit et le devoir de rejeter une suggestion.

Le bon développeur n’est donc ni celui qui refuse l’IA par principe, ni celui qui accepte chaque réponse. C’est celui qui reste capable de comprendre, de vérifier, d’expliquer et de décider. L’outil peut accélérer son travail ; la qualité vient toujours de la discipline avec laquelle il l’emploie.

Sources

La rédaction — Opus Stellar CI