Formation Développeur augmenté par l’IA : pratiquer le développement agentique Best

– Assistant de complétion, chat, agent de code : ce qui change quand l’IA lit le dépôt, modifie plusieurs fichiers et exécute des commandes
– La boucle agentique : lire, planifier, éditer, exécuter, vérifier, et pourquoi chaque étape peut dérailler
– Tokens et fenêtre de contexte : ce que l’agent voit réellement et pourquoi il se dégrade sur les longues sessions
– Erreurs typiques du code généré : API inventées, code plausible mais faux, tests contournés, excès de confiance
– Vibe coding ou agentic coding : génération sans contrôle ou collaboration cadrée et vérifiée
– Panorama des outils : agents en ligne de commande, agents intégrés à l’IDE, agents cloud, et critères de choix (stack, confidentialité, coût, pratiques d’équipe)
– Quand ne pas confier une tâche à un agent : code critique mal testé, exigences floues, apprentissage d’une notion

– Mise en route : installation dans le terminal ou l’IDE, connexion au dépôt, premier échange sur le projet
– Modes d’approbation et permissions : lecture, écriture, exécution de commandes, et réglages adaptés à chaque contexte
– Exécution isolée : intérêt d’un environnement cloisonné dès que l’agent agit de façon autonome
– Confidentialité : données envoyées au fournisseur, exclusion de fichiers, secrets maintenus hors de portée de l’agent
– Coûts : abonnements, consommation de tokens, choix du modèle selon la tâche
– Git comme filet de sécurité : branche de travail, commits fréquents, retour arrière sur une modification ratée

– Le contexte, premier levier de qualité : pourquoi une demande juste échoue sans les bonnes informations
– Fichier d’instructions du projet (AGENTS.md et équivalents propres à chaque outil) : commandes de build et de test, conventions, architecture, interdits
– Ce qu’il ne faut pas y mettre : documentation exhaustive, règles contradictoires, informations qui changent souvent
– Structurer une demande de développeur : objectif, contraintes, fichiers concernés, critères d’acceptation
– Pointer la bonne information : fichiers ciblés, extraits de documentation, exemples de code existant, captures d’écran
– Gérer la session : repartir à neuf, faire résumer, découper une tâche trop large
– Itérer sur une réponse : corriger la trajectoire plutôt que tout redemander

– Explorer une codebase inconnue : faire cartographier l’architecture, les flux et les zones à risque avant de toucher au code
– Mode plan : faire proposer un plan, le discuter et l’amender avant toute modification
– Implémenter par petites étapes vérifiables : un changement, un test, un commit
– Tests d’abord quand c’est possible : écrire ou faire écrire le test qui définit le comportement attendu
– Déboguer avec l’agent : reproduire, isoler, corriger, puis ajouter le test de non-régression
– Refactoring de code legacy : sécuriser par des tests de caractérisation avant de restructurer
– Documentation et messages de commit : produire à partir du code et du diff une documentation cohérente

– Des mécanismes communs aux principaux agents : mêmes concepts, noms et formats propres à chaque outil
– Commandes et prompts réutilisables : encapsuler une tâche récurrente (revue, préparation de PR, rédaction de tests)
– Skills : procédures et connaissances chargées seulement quand la tâche les demande
– Sous-agents : déléguer une recherche ou une revue dans un contexte isolé, sans encombrer la session principale
– Hooks : déclencher automatiquement un contrôle à chaque modification (formatage, lint, tests)
– MCP (Model Context Protocol) : brancher l’agent sur des outils existants (navigateur, documentation à jour, ticketing) et évaluer la confiance accordée à un serveur
– Choisir le bon mécanisme : instruction, commande, skill, hook ou serveur MCP selon le besoin