Code généré par IA : qui en prend la responsabilité ?

Une fonction peut être produite en quelques secondes et demander beaucoup plus de temps pour être comprise. L’usage d’un assistant de développement déplace une partie du travail ; il ne supprime ni la revue ni la responsabilité du logiciel livré.

Ce que précise le projet Linux

La documentation du noyau Linux sur les assistants de code attribue la responsabilité de la contribution à une personne. Elle interdit à un agent d’ajouter lui-même la signature du Developer Certificate of Origin et prévoit une attribution de l’assistance utilisée.

C’est une règle de contribution propre à ce projet. Pour une entreprise qui achète un logiciel, elle offre aussi une question de départ : qui comprend le changement et peut en répondre ? Cette transposition est une recommandation d’organisation, pas une obligation contractuelle issue de Linux.

Une revue doit porter sur le comportement

Un code bien présenté peut appliquer une mauvaise règle, oublier une permission ou mal gérer une donnée absente. La personne qui le valide doit relier le changement au besoin et examiner les conséquences possibles.

• Quel scénario le changement rend-il possible ?
• Que se passe-t-il si une donnée manque ou arrive deux fois ?
• Qui a le droit de consulter ou de modifier l’information ?
• Quel test montre que le comportement attendu est obtenu ?

Ces questions s’appliquent aussi au code écrit sans assistant. Elles rendent la validation plus utile qu’un simple contrôle de mise en forme.

Demander des preuves proportionnées au risque

Une correction de libellé ne demande pas les mêmes vérifications qu’un changement de facturation ou de droits d’accès. Les tests doivent cibler les erreurs qui auraient un coût réel pour les utilisateurs ou l’exploitation.

Dans un projet sur mesure, le compte rendu de livraison peut nommer le scénario vérifié, le résultat et les limites du test. Une démonstration réussie avec un jeu de données ne prouve pas toutes les capacités du système.

Conserver les informations nécessaires à la reprise

Le prochain développeur doit comprendre pourquoi le choix a été fait. Documenter une contrainte, une dépendance et un compromis aide davantage que conserver la conversation complète avec un assistant.

Avant de commander une application, demandez comment les changements sont relus, comment les licences sont examinées et comment les anomalies sont prises en charge. L’outil utilisé pour écrire le code compte moins que la capacité de l’équipe à expliquer et maintenir le résultat.