Aperçu gratuit · Module 1 · Leçon 1
Une fonction générée, relue et testée en vingt minutes
Demander une fonction à un assistant de code, écrire d'abord les cas limites, puis accepter le code seulement quand ces tests passent. Leçon d’aperçu gratuite de la formation « IA pour développeurs », lisible en entier sans compte, avec ses sources officielles datées.
Objectif
Obtenir aujourd'hui, avec l'assistant de code de votre choix, une petite fonction utile dont vous avez vous-même écrit les tests des cas limites, et repérer l'erreur qu'un code « qui a l'air juste » laisse passer.
Ce que vous saurez faire
- Formuler une demande de code avec un contrat explicite : entrées, sorties, cas limites, interdits.
- Écrire quatre tests de cas limites avant de lire le code proposé.
- Décider en trois questions si une proposition peut entrer dans votre branche.
Contenu
Un assistant de code (complétion dans l'éditeur, conversation ou agent) produit vite un code lisible. La difficulté n'est pas d'en obtenir, c'est de savoir s'il est juste. Les éditeurs le disent eux-mêmes : un code proposé peut sembler valide sans être correct, ni refléter l'intention du développeur . GitHub demande ainsi de toujours relire et tester soigneusement le code généré, surtout pour les applications sensibles .
Cette leçon installe le geste de base de toute la formation : les tests d'abord, le code ensuite. Vous écrivez les cas qui comptent avant de lire la proposition, pour ne pas vous laisser guider par elle.
Le contrat en cinq lignes
- Signature. Nom de la fonction, types des paramètres et du résultat.
- Comportement. Une phrase, sans ambiguïté.
- Cas limites. Entrée vide, valeurs égales, ordre inattendu, bornes.
- Interdits. Pas de nouvelle dépendance, pas d'accès réseau, pas de modification de l'entrée.
- Livrable. Le code seul, puis la liste des hypothèses faites.
Les trois questions avant d'accepter
- Les tests passent-ils ? Vos tests, pas ceux que l'outil a écrits pour lui-même.
- Est-ce que je comprends chaque ligne ? Une ligne que vous ne savez pas expliquer ne part pas en revue.
- Le code respecte-t-il les interdits ? Dépendance ajoutée, entrée modifiée, effet de bord : refus.
Workflow
Du contrat à la fusion : le code généré en cinq temps
1. Trier : vérifier que rien d'interdit (secret, donnée réelle, code protégé) n'est visible par l'outil. 2. Contracter : écrire le contrat en cinq lignes (signature, comportement, cas limites, interdits, livrable). 3. Tester d'abord : écrire les tests des cas limites à partir du contrat, avant de lire la proposition. 4. Relire : appliquer la grille en six passes (intention, entrées, sorties dangereuses, secrets, erreurs, dépendances). 5. Fusionner : tests verts, chaque ligne comprise, demande de fusion qui signale l'usage d'un assistant, revue d'un collègue.
- Quand l’utiliser
- Pour toute fonction ou tout correctif proposé par un assistant, quelle que soit sa taille.
- Ce qu’il faut personnaliser
- Pour une modification triviale (renommage, formatage), les étapes 2 et 3 peuvent se réduire à « les tests existants passent ». Ne sautez jamais l'étape 1 ni l'étape 4.
- Exemple
- Fusion de créneaux : contrat écrit, quatre tests, une proposition qui suppose une liste triée, corrigée avant fusion.
- Limites
- Écrire les tests après avoir lu le code ; accepter une ligne incomprise ; confondre « les tests de l'outil passent » et « mes tests passent ».
Données à ne pas envoyer
- Clés d'API, jetons d'accès, mots de passe, clés privées et fichiers de clés TLS
- Fichiers .env, fichiers de configuration de production, sauvegardes de bases de données
- Données réelles de clients, de patients ou de collaborateurs (noms, adresses, numéros, journaux nominatifs)
- Code couvert par un accord de confidentialité ou un secret d'affaires non ouvert à l'outil
- Adresses et noms de machines internes, schémas de réseau
Exemple réel
Cas fictif, situation réaliste. Mehdi, développeur chez Tramelis, éditeur fictif d'un logiciel de réservation de salles à Lyon, doit fusionner des créneaux qui se chevauchent. Il écrit le contrat en cinq lignes, puis quatre tests : liste vide, créneaux non triés, créneaux qui se touchent (10 h-11 h et 11 h-12 h), créneau inclus dans un autre.
La proposition de l'assistant est élégante et passe trois tests sur quatre. Elle suppose une liste déjà triée : les créneaux non triés restent séparés. Mehdi ajoute le tri, relance les tests, tout passe. Il note aussi que la fonction modifiait la liste reçue : il exige une copie. Durée totale : dix-huit minutes, dont six pour les tests.
À vous de jouer
Utilisez la spécification fictive ci-dessous. Temps à prévoir : environ 20 minutes.
Modèle
Spécification FICTIVE : fusionner des créneaux
DONNÉES FICTIVES — exercice. Fonction : fusionner_creneaux(creneaux: list[tuple[int, int]]) -> list[tuple[int, int]] Unités : minutes depuis minuit (600 = 10 h 00). Comportement : renvoie la liste des créneaux fusionnés, triée par début, où deux créneaux qui se chevauchent OU se touchent (fin de l'un = début de l'autre) ne forment plus qu'un. Règles : la liste reçue n'est pas modifiée ; une liste vide renvoie une liste vide ; on suppose début < fin pour chaque créneau. Tests à écrire AVANT de demander le code : 1. fusionner_creneaux([]) == [] 2. fusionner_creneaux([(720, 780), (600, 660)]) == [(600, 660), (720, 780)] 3. fusionner_creneaux([(600, 660), (660, 720)]) == [(600, 720)] 4. fusionner_creneaux([(600, 780), (630, 660)]) == [(600, 780)] Test bonus : la liste passée en argument est identique avant et après l'appel. CORRIGÉ (erreurs fréquentes des propositions) : pas de tri préalable (le test 2 ou une variante non triée échoue) ; comparaison stricte (fin > début suivant) qui ne fusionne pas les créneaux qui se touchent (test 3) ; tri en place avec list.sort() qui modifie l'entrée (test bonus) ; prise de la fin du dernier créneau au lieu du maximum des fins (test 4).
- Quand l’utiliser
- Leçon 1, exercice de première victoire.
- Ce qu’il faut personnaliser
- Traduisez la signature dans votre langage ; gardez les quatre tests à l'identique.
- Exemple
- Proposition fictive qui passe trois tests sur quatre : le tri manquant est révélé par le test 2.
- Limites
- Lire la proposition avant d'écrire les tests ; oublier le test bonus.
Données à ne pas envoyer
- Clés d'API, jetons d'accès, mots de passe, clés privées et fichiers de clés TLS
- Fichiers .env, fichiers de configuration de production, sauvegardes de bases de données
- Données réelles de clients, de patients ou de collaborateurs (noms, adresses, numéros, journaux nominatifs)
- Code couvert par un accord de confidentialité ou un secret d'affaires non ouvert à l'outil
- Adresses et noms de machines internes, schémas de réseau
- Écrivez les quatre tests du modèle avant d'ouvrir l'assistant.
- Collez le contrat en cinq lignes dans l'outil de votre choix et récupérez le code.
- Lancez vos tests. Notez ceux qui échouent et pourquoi.
- Appliquez les trois questions. Acceptez, corrigez ou refusez, et écrivez une phrase de justification.
Prompt / modèle
Prompt
Demander une fonction avec un contrat explicite
Rôle : tu es un développeur [langage] rigoureux. Tâche : écris la fonction décrite ci-dessous, et rien d'autre. Signature : [nom(paramètres) -> type de retour] Comportement : [une phrase sans ambiguïté] Cas limites à gérer : [entrée vide ; valeurs égales ; ordre inattendu ; bornes] Interdits : aucune nouvelle dépendance ; aucun accès réseau ou fichier ; ne modifie pas l'entrée reçue. Livrable : 1) le code ; 2) la liste numérotée des hypothèses que tu as faites ; 3) les cas limites que tu n'as pas su traiter. N'écris pas de tests : je les ai déjà.
- Quand l’utiliser
- Pour toute fonction autonome demandée à un assistant en mode conversation.
- Ce qu’il faut personnaliser
- En mode complétion, écrivez le contrat en commentaire au-dessus de la signature. Pour une méthode de classe, ajoutez l'état de l'objet que la méthode peut lire ou modifier.
- Exemple
- fusionner_creneaux(creneaux: list[tuple[int, int]]) -> list[tuple[int, int]] avec quatre cas limites et l'interdiction de modifier la liste reçue.
- Limites
- Un comportement vague (« gère les créneaux ») ; oublier les interdits ; demander les tests dans la même demande que le code.
Données à ne pas envoyer
- Clés d'API, jetons d'accès, mots de passe, clés privées et fichiers de clés TLS
- Fichiers .env, fichiers de configuration de production, sauvegardes de bases de données
- Données réelles de clients, de patients ou de collaborateurs (noms, adresses, numéros, journaux nominatifs)
- Code couvert par un accord de confidentialité ou un secret d'affaires non ouvert à l'outil
- Adresses et noms de machines internes, schémas de réseau
Piège à éviter
À retenir
- Un contrat en cinq lignes : signature, comportement, cas limites, interdits, livrable.
- Vos tests de cas limites d'abord ; la proposition ensuite.
- Trois questions avant d'accepter : tests verts, chaque ligne comprise, interdits respectés.
Mini-quiz
Le mini-quiz de cette leçon fait partie de l’évaluation : il est proposé dans l’espace membre.
Sources
Preuves de cette leçon
Chaque affirmation qui peut évoluer renvoie à une source primaire, avec sa date de consultation.
1 Selon la documentation de GitHub sur l'usage responsable de Copilot, le code proposé peut sembler valide sans être correct sur le plan sémantique ou syntaxique, ni refléter l'intention du développeur.
- GitHub Docs — Responsible use of GitHub Copilot inline suggestions docs.github.com · consultée le
2 GitHub recommande de toujours relire et tester soigneusement le code généré par Copilot, en particulier pour les applications sensibles du point de vue de la sécurité, et de suivre les bonnes pratiques de code sécurisé (pas de mot de passe en dur, pas d'injection SQL).
- GitHub Docs — Responsible use of GitHub Copilot inline suggestions docs.github.com · consultée le
- GitHub Docs — Responsible use of GitHub Copilot Chat docs.github.com · consultée le