Sachez exactement ce que vous envoyez, ce que vaut juridiquement le code généré et comment les biais des modèles orientent vos décisions techniques.
Ouvrir cette leçon dans KodokonChaque prompt est une transmission de données à un tiers. Avant d'utiliser un assistant en contexte professionnel, trois questions doivent avoir une réponse documentée. Rétention : combien de temps le fournisseur conserve-t-il vos conversations, et qui peut y accéder (support, sécurité, réquisition judiciaire) ? Entraînement : vos données servent-elles à entraîner les futurs modèles, et l'option de retrait est-elle activée sur votre compte - les offres grand public et les offres entreprise diffèrent presque toujours sur ce point ? Contrat : votre employeur ou vos clients vous autorisent-ils à transmettre ce code, sachant que les clauses de confidentialité que vous avez signées s'appliquent aussi à un prompt ? Un extrait de code peut sembler anodin ; accompagné de noms de domaine internes, de structures de tables et de messages d'erreur avec chemins complets, il décrit votre système d'information.
La bonne pratique est la minimisation : n'envoyer que le strict nécessaire au raisonnement. C'est une compétence en soi - construire un exemple minimal reproductible avec des noms génériques - et elle a une vertu pédagogique inattendue : isoler un problème pour le décrire abstraitement oblige à le comprendre. Le prompt suivant transforme cette contrainte de confidentialité en exercice de diagnostic.
Contexte : je travaille sur du code propriétaire que je ne peux pas partager. Je vais te décrire mon problème de façon abstraite, avec des noms génériques et sans coller le code réel.
Description : [PSEUDO-CODE de la structure concernée, MESSAGE D'ERREUR avec chemins et identifiants masqués, VERSIONS des bibliothèques impliquées].
Ta mission :
1. Si ma description est trop vague pour raisonner, indique exactement quelle information te manque et pourquoi - je déciderai si je peux la fournir sous forme anonymisée.
2. Raisonne uniquement sur ma description : ne me demande jamais de coller le fichier complet.
3. Propose des hypothèses de cause classées par probabilité, et pour chacune un test précis que je peux exécuter en local pour la confirmer ou l'éliminer.
Format : tableau hypothèse / probabilité / test de vérification. Je reviendrai avec les résultats des tests.Deuxième dossier : les licences du code généré. Le droit n'est pas stabilisé et varie selon les juridictions, mais trois faits sont établis. Un : les modèles sont entraînés sur du code sous licences variées, y compris des licences contaminantes comme la GPL, et peuvent restituer des extraits très proches de leur source - surtout pour des algorithmes célèbres ou des extraits massivement dupliqués. Deux : dans plusieurs juridictions, une production purement machinale sans apport créatif humain est difficilement protégeable par le droit d'auteur, ce qui fragilise vos prétentions sur du code accepté tel quel. Trois : certains fournisseurs proposent une indemnisation contractuelle en cas de réclamation pour contrefaçon, et des filtres bloquant les restitutions trop proches du corpus - vérifiez que ces protections figurent dans votre offre, pas seulement dans la brochure. En pratique : plus un extrait généré est long, spécifique et accepté sans retouche, plus le risque juridique monte.
Troisième dossier : les biais. Un modèle restitue les régularités statistiques de son corpus, et trois biais affectent directement vos décisions techniques. Le biais de popularité : les solutions sur-représentées dans les données (frameworks dominants, patrons à la mode d'il y a deux ans) sont recommandées par défaut, même quand votre contexte appelle autre chose - le corpus a toujours un temps de retard sur l'état de l'art. Le biais de complaisance : les modèles sont optimisés pour satisfaire l'utilisateur et tendent à valider votre prémisse ; demandez « pourquoi mon approche microservices est-elle la bonne ? » et vous recevrez des confirmations, pas un contre-avis. Le biais d'autorité inversé : la fluidité du ton produit une impression de certitude sans corrélation avec la fiabilité. La parade est procédurale : forcer la contradiction.
Tu viens de me recommander [SOLUTION OU TECHNOLOGIE]. Avant que je décide, change de posture : tu es maintenant un ingénieur expérimenté chargé de plaider CONTRE cette recommandation.
1. Donne les 3 meilleurs arguments contre ta propre réponse, chacun illustré par un scénario concret où elle échoue.
2. Cite au moins une alternative sérieuse que tu n'avais pas mentionnée, et explique honnêtement pourquoi elle était absente de ta première réponse.
3. Évalue ce que ta recommandation initiale doit à la popularité de cette solution dans tes données d'entraînement, plutôt qu'à mon contexte précis, que je te rappelle : [VOTRE CONTEXTE : taille d'équipe, contraintes, existant].
Format : deux colonnes Pour / Contre, puis ta recommandation révisée en une phrase, avec ton niveau de confiance et ce qui pourrait le faire changer.