Développer sans être développeur avec Claude (IA)
Le contexte
Bluffé par un premier essai de Claude, je voulais en tester les limites. J’ai donc décidé de lui faire développer un outil interne de ticketing.
Je ne suis pas développeur à proprement parler mais j’ai beaucoup d’expérience de certains languages (Python notamment). Je serais donc le chef de projet, lui le développeur.
Par ailleurs, comme le projet n’était pas une priorité mais un test, je devais pouvoir y revenir quand je serais disponible, sans pression.
Les résultats – le négatif
Malgré son excellente gestion du contexte, l’IA a parfois quelques difficultés à garder du recul sur le projet. Il n’est pas rare qu’elle oublie des contraintes importantes du projet lors de la résolution de sous-tâches, de demande ad-hoc ou de bug.
De la même manière certains problèmes imbriqués lors de la résolution de bugs lui donnent des difficultés. J’ai rencontré un problème dû à une surcharge de fichiers css, et non seulement l’IA bouclait sur des solutions incohérentes, mais elle n’arrivait pas non plus à proposer une méthode de débuggage.
Les résultats – le positif
Mais ces remarques sont assez exigeantes de ma part et elles pourraient certainement s’appliquer aussi à des personnes. Je suis le premier à régulièrement manquer de prise de recul.
Au contraire, l’IA excelle la plupart du temps à proposer des solutions, et démontre une incroyable connaissance des langages rencontrés et une grande pédagogie.
Et donc ?
Pour moi et mon profil spécifique, c’est clair, ça fonctionne, en veillant à ne pas déléguer la structuration et le suivi. Je vous partage au passage 5 conseils d’utilisation de Claude pour développer.
Comment développer avec Claude – 5 tips de méthode
- Je structure
Je commence par présenter mon idée de base à Claude (souvent Opus pour cette phase) et lui demander d’approfondir avec moi : « Je voudrais développer un outil de ticketing, voilà les fonctionnalités auxquelles j’ai pensé, voilà les spécificités, les contraintes, et voilà pour moi le modèle de données général. Qu’en penses-tu ? Je voudrais que le backend soit développé en python, qui des autres technologies nécessaires ? »
Cette première phase est réellement une phase de découverte. On peut au passage demander à Claude de nous expliquer ses choix et de nous informer : « Qu’est-ce que cette technologie ? Pourquoi celle-ci plutôt que … ? »
Je priorise à ce moment-là aussi les développements à venir et je peux prévenir Claude de ce qui changera à long terme : par exemple « je ne veux pas de système de sécurité le temps d’initier les développements mais il faut prévoir à terme d’utiliser çi ou ça ».
2. Je demande des plans de développement
Chaque nouvelle phase de développement commence par la rédaction d’un plan de développement détaillé. Pendant cette phase, je demande à Claude de ne pas coder tout de suite, mais de passer en revue les éléments nécessaires au développement de la fonctionnalité. Je demande à Claude de sauvegarder ce plan dans des fichiers au sein d’un dossier dédié. Ces fichiers servent non seulement à suivre l’avancement des développements, mais permettent aussi plus facilement de modifier certains éléments voire la stratégie de développement.
(NB : Github Copilot vient de lancer une fonctionnalité similaire. A creuser)
3. Je commit souvent
Claude explose la rapidité de production, et génère très facilement du code découpé : classes, script, fonctions, page web, etc. et il est très facile d’avoir des dizaines de modifications en quelques minutes. Sauvegarder et pousser sur un repo régulièrement me permet de marquer les backups et de tenter des refactorisations importantes sereinement.
4. Je m’occupe des bugs
Comme je l’ai mentionné, le traitement de bugs peut amener des problèmes supplémentaires. Notamment, il n’est pas rare que Claude « boucle » sur lui-même : pour corriger A il met en place B, ce qui génère une nouvelle erreur C, qu’il corrige en proposant de rétablir A, en oubliant complètement l’erreur que cela générait.
Je mets donc la règle suivante en place si Claude n’arrive pas à régler le bug en une ou deux interventions, ou si je vois que le problème est particulièrement complexe, je reprends la main sur le code et Claude redevient un assistant : « D’où vient l’erreur ? Peux-tu implémenter des logs à cet endroit ? Que fait ce morceau de code ? Où est définie cette variable ? etc. » On a facilement la flemme, mais c’est le moment de se former à la technologie et d’amener la prise de recul nécessaire.
5. J’explicite le plus possible
Les fichiers d’instructions sont des fichiers textes dans lesquels on peut préciser certains comportements, l’environnement technique et des spécificités d’utilisation des connecteurs (serveurs MCP). Je l’utilise pour lui indiquer certaines spécificités techniques et lui demander par exemple de ne pas me flatter constamment.
Intéressé par la méthode ?
Discutons-en autour d’un café…
