Oui c'est super adapté pour faire un prototype, expérimenter et itérer rapidement. Un gros défaut dans le monde de l'ingénierie logiciel, c'est qu'on a tendance à faire des prototypes et à ensuite les envoyer en prod. C'est déjà une très mauvaise habitude, mais ça deviendra encore pire avec l'IA (du moins tant qu'elle n'aura pas une vision globale).
Mon expérience personnelle avec l'IA générative pour le code c'est qu'elle excelle dans certains domaines: les taches répétitives, bien définies et peu ambiguës. Si on a une spécification de format de fichier et qu'on veut écrire un parseur par exemple. La génération de tests unitaires est aussi un très bon exemple.
C'est un outil très performant du moment qu'on le guide suffisamment. Mais il faut aussi des taches sur lesquels la génération par IA suivie d'une vérification (et potentiellement correction) par un humain fait gagner du temps. Si la vérification est presque aussi complexe que la génération, il y a de fortes chances de perdre beaucoup de temps. Disons qu'il faut prévoir jusqu'à une demi-douzaine d'itérations pour être sûr.
Récemment j'ai utilisé l'IA pour générer du code plus complexe avec des résultats mitigés. La leçon générale que j'en tire c'est qu'il faut un prompt précis qui fournisse les étapes à suivre et l'architecture globale que l'on désire. Il faut fournir plus de détails que ce qu'on ferait typiquement avec un humain, même un junior (ou alors un junior "du bas du panier").
Mais j'ai aussi commencé à faire une première passe de revue de code par l'IA elle même et ça fournit, là aussi, des résultats parfois plutôt bons pour créer un prompt pour refactorer le code. Il faut juste faire le tri...
Au final il y a une véritable compétence à développer pour savoir quand et comment utiliser ces outils de manière efficace. En l'état actuel, ce n'est pas facile: les performances évoluent rapidement, le modèle utilisé change la donne et il peut changer automatiquement par manque de crédit, un modèle plus récent peut être meilleur pour une tache et moins bon pour une autre, etc...
[^] # Re: Utile pour le oneshot
Posté par Colin Pitrat (site web personnel) . En réponse au journal Retour d'expérience sur le développement d'une application par l'utilisation d'IA. Évalué à 5. Dernière modification le 31 janvier 2026 à 09:29.
Oui c'est super adapté pour faire un prototype, expérimenter et itérer rapidement. Un gros défaut dans le monde de l'ingénierie logiciel, c'est qu'on a tendance à faire des prototypes et à ensuite les envoyer en prod. C'est déjà une très mauvaise habitude, mais ça deviendra encore pire avec l'IA (du moins tant qu'elle n'aura pas une vision globale).
Mon expérience personnelle avec l'IA générative pour le code c'est qu'elle excelle dans certains domaines: les taches répétitives, bien définies et peu ambiguës. Si on a une spécification de format de fichier et qu'on veut écrire un parseur par exemple. La génération de tests unitaires est aussi un très bon exemple.
C'est un outil très performant du moment qu'on le guide suffisamment. Mais il faut aussi des taches sur lesquels la génération par IA suivie d'une vérification (et potentiellement correction) par un humain fait gagner du temps. Si la vérification est presque aussi complexe que la génération, il y a de fortes chances de perdre beaucoup de temps. Disons qu'il faut prévoir jusqu'à une demi-douzaine d'itérations pour être sûr.
Récemment j'ai utilisé l'IA pour générer du code plus complexe avec des résultats mitigés. La leçon générale que j'en tire c'est qu'il faut un prompt précis qui fournisse les étapes à suivre et l'architecture globale que l'on désire. Il faut fournir plus de détails que ce qu'on ferait typiquement avec un humain, même un junior (ou alors un junior "du bas du panier").
Mais j'ai aussi commencé à faire une première passe de revue de code par l'IA elle même et ça fournit, là aussi, des résultats parfois plutôt bons pour créer un prompt pour refactorer le code. Il faut juste faire le tri...
Au final il y a une véritable compétence à développer pour savoir quand et comment utiliser ces outils de manière efficace. En l'état actuel, ce n'est pas facile: les performances évoluent rapidement, le modèle utilisé change la donne et il peut changer automatiquement par manque de crédit, un modèle plus récent peut être meilleur pour une tache et moins bon pour une autre, etc...