Un contrôleur collé « juste pour trouver le bug », une clé d'accès oubliée ligne 12 : la relecture de code par IA fuit souvent par des gestes anodins. Six erreurs courantes, et comment travailler sans elles.
Mardi, 16 h 30. Un test d'intégration échoue depuis le matin, la mise en production est prévue jeudi. Le développeur sélectionne le contrôleur entier, quatre cents lignes, le colle dans une IA grand public et tape : « trouve le bug ». La réponse arrive, juste. Personne ne remarque que la ligne 12 contenait une clé d'accès à l'environnement de recette, que les commentaires citaient le client par son nom, et que la règle de calcul des remises, celle que l'équipe a mis deux ans à affiner, est désormais chez un fournisseur que personne n'a choisi.
C'est l'erreur que l'on voit le plus : non pas une imprudence spectaculaire, mais un copier-coller fait sous pression. L'IA est pourtant un très bon relecteur de code. Encore faut-il savoir ce qu'on lui donne, et où.
Un code écrit pour un employeur ou pour un client ne vous appartient généralement pas. Il relève du secret des affaires, que le droit protège en France comme en Suisse ; il est souvent couvert par une clause de confidentialité dans le contrat de travail ou de prestation ; et la charte informatique de l'entreprise interdit fréquemment de transmettre du code à un service non validé. Chez un prestataire, le code appartient parfois au client, qui n'a jamais autorisé qu'il sorte.
S'y ajoutent les données personnelles qui se glissent dans le code : jeux de test copiés de la production, journaux d'erreurs, adresses dans des fixtures. Celles-là relèvent du RGPD ou de la loi suisse sur la protection des données, quelle que soit la nature du projet.
Un fichier isolé paraît anodin. Mais c'est souvent le fichier qui compte : l'algorithme de tarification, la logique d'un moteur de recommandation, le contournement d'une limite d'une bibliothèque. Une fois collé dans une IA grand public, il est chez un tiers qui peut conserver l'historique, et dont le fournisseur peut être soumis à des lois étrangères qui l'obligent à communiquer ce qu'il détient.
La parade : faire la relecture sur un modèle confidentiel. Dans IA Confidential, les modèles locaux et spécialisés sont des modèles ouverts installés sur des serveurs en Suisse, sous la loi suisse sur la protection des données et hors du champ du CLOUD Act ; ils ne transmettent rien à des tiers. Le choix du modèle est automatique ou manuel, et pour une relecture, un modèle confidentiel est le bon point de départ.
Clés d'accès en dur, chaîne de connexion à la base, jeton d'un service tiers, fichier de configuration d'environnement joint « pour le contexte », trace d'erreur contenant l'adresse électronique d'un utilisateur. On les colle sans les voir, parce qu'on cherche un bug, pas une fuite.
La parade : retirer les secrets avant tout envoi, même vers un outil confidentiel. Une relecture n'a jamais besoin de la vraie valeur d'une clé : remplacez-la par [CLÉ_API], et les données réelles par des valeurs inventées. Si une clé est déjà partie quelque part, changez-la. Le guide sur les données à ne jamais coller dans une IA détaille le cas des secrets d'accès. La demande la plus simple montre qu'on peut s'en passer :
Voici une trace d'erreur PHP et la méthode qui la déclenche. J'ai remplacé les identifiants et les données par des valeurs fictives. Explique-moi la cause probable en trois phrases, puis propose la correction la plus petite possible.
Renommer calculRemiseClientX en f1, retirer le nom de l'entreprise des commentaires : on a l'impression d'avoir rendu le code anonyme. Or ce qui fait la valeur d'un code propriétaire, c'est sa logique, et elle reste intacte. Les noms de tables, les domaines internes et les messages d'erreur suffisent souvent à reconnaître le projet.
Le filtre confidentialité d'IA Confidential ne prétend pas faire mieux. Quand vous choisissez un modèle externe, il détecte d'abord les données sensibles et vous laisse décider : répondre avec un modèle confidentiel, message intact ; envoyer une version anonymisée, que vous pouvez relire et corriger ; ou envoyer tel quel. Pour une pièce jointe, seuls les extraits utiles partent, pseudonymisés. Mais ce qu'il remplace, ce sont des données qui identifient : un nom, une adresse, un identifiant. Pas un algorithme.
La parade : distinguer deux types de questions. « Pourquoi ce tri est-il lent ? » sur votre module de facturation reste sur un modèle confidentiel. « Comment fonctionne le verrouillage optimiste en général ? » peut aller vers un modèle externe, sans votre code. Pour les noms que vous ne voulez jamais voir sortir, nom du client, nom de code du projet, domaine interne, écrivez-les dans les consignes d'anonymisation du panneau Confidentialité : ce sont précisément les éléments qu'aucun détecteur ne devine seul. Le guide anonymisation ou pseudonymisation explique la différence.
Deux excès opposés. Soit on joint un seul fichier, et l'IA invente le comportement des classes qu'elle ne voit pas. Soit on lui confie la racine du projet « pour qu'elle ait tout », avec la configuration de production, les sauvegardes de base et les scripts de déploiement.
La parade : donner le contexte utile, et lui seul. Sur ordinateur, avec Chrome, Edge ou Opera, vous pouvez ajouter à un espace jusqu'à dix dossiers de votre machine, avec des droits par dossier : recherche, lecture, écriture. Pour une relecture, ajoutez le dossier du module concerné plutôt que la racine, sans le droit d'écriture, et cochez l'option « Modèles confidentiels » : le dossier n'est alors jamais envoyé à un modèle externe. Avec un compte connecté, l'assistant y retrouve automatiquement les passages utiles à votre question. Sur un autre navigateur, joignez les fichiers nécessaires à votre message : ils sont lus dans votre navigateur, et aucun n'est conservé sur nos serveurs.
Sans critère, la relecture est générique : des remarques de style, un conseil de nommage, une suggestion d'ajouter des commentaires. La vraie question (une fuite mémoire, une requête en boucle, une faille d'injection) passe entre les lignes.
La parade : fixer le cadre une fois, puis préciser à chaque demande. Créez un espace de type « Développement » par projet : il propose des exemples pour lire, corriger et écrire du code, et des réponses détaillées. Dans l'onglet Assistant, les consignes d'espace posent le langage et sa version, le cadriciel, vos conventions, ce qui est hors sujet ; elles priment sur vos préférences générales. La demande dit ensuite ce que vous cherchez :
Relis la méthode d'import ci-dessous, appelée sur des fichiers de 50 000 lignes. Je ne veux pas de remarques de style. Cherche uniquement : les requêtes exécutées dans une boucle, les chargements complets en mémoire, et les cas où une ligne invalide interrompt tout l'import. Pour chaque point, cite la ligne et estime l'effet sur un gros fichier.
L'IA se trompe avec assurance. Elle invente une méthode qui n'existe pas dans votre version de la bibliothèque, propose une correction qui fait passer le test sans traiter la cause, déclare un code « sûr » alors qu'une faille lui a échappé. Une relecture par IA n'est pas un audit de sécurité, et un correctif accepté en vitesse finit en production jeudi.
La parade : exiger qu'elle s'explique, et vérifier. Demandez des numéros de ligne, des hypothèses explicites, ce qu'elle n'a pas pu voir. Puis passez chaque correction par vos tests et par la revue humaine habituelle de l'équipe. La demande la plus poussée ressemble à ceci :
Voici le différentiel d'une demande de fusion qui modifie notre authentification par jeton, avec les deux fichiers qu'il touche. Fais une relecture de sécurité : contrôle d'accès, validation des entrées, gestion des erreurs, comparaison des jetons. Pour chaque risque, donne la ligne, un scénario d'attaque concret et la correction minimale. Liste ensuite ce que tu n'as pas pu vérifier faute de voir le reste du code, et propose trois tests qui prouveraient que la correction fonctionne.
La responsabilité du code fusionné reste celle de l'équipe qui le fusionne.
Avec un modèle confidentiel, votre code quitte votre poste pour être traité sur des serveurs situés en Suisse, puis rien n'est conservé de notre côté. Un dossier ajouté avec l'option « Modèles confidentiels » n'est jamais envoyé à un modèle externe, et l'index qui permet d'y retrouver les passages reste dans le dossier, sur votre ordinateur. Les fichiers joints sont lus dans votre navigateur.
Avec un modèle externe, c'est vous qui décidez de ce qui part, après le passage du filtre : version anonymisée, extraits pseudonymisés, ou message tel quel si vous l'assumez. Votre profil personnel, lui, n'est jamais envoyé à un modèle externe. Gardez en tête que l'anonymisation masque des noms, pas une logique : un code dont l'algorithme est le secret reste sur les modèles confidentiels.
L'historique de vos discussions, extraits de code compris, vit dans votre navigateur et nulle part ailleurs. Sur un poste partagé ou une machine de recette commune, il est lisible par quiconque utilise la même session : travaillez dans une session personnelle et déconnectez-vous en partant. Et un secret retiré du message n'est protégé que s'il l'est aussi dans votre dépôt.
Si votre équipe hésite encore à autoriser l'IA, les arguments du guide utiliser l'IA au travail sans risque valent aussi pour un service de développement. Pour essayer sur un module sans enjeu, secrets retirés : ouvrez le chat.
