Auparavant, certains internautes m’ont demandé quel était mon processus de développement pour l’IA. Par hasard, j’ai mis en place récemment une petite fonctionnalité avec l’IA, et ça vaut la peine de la présenter comme étude de cas, et aussi comme référence.
L’origine de cette fonctionnalité vient du fait qu’un internaute m’a laissé un message dans les Issues GitHub (figure 1). Il m’a demandé si je pouvais ajouter à mon application BaoCut, qui fait de la transcription et de la traduction de sous-titres, une fonction de transcription à distance.
En d’autres termes, j’ai deux ordinateurs : l’un est une machine hautes performances A équipée d’une carte graphique Nvidia ; l’autre est juste un ordinateur de bureau B au quotidien. Je veux profiter de la puissance de calcul de l’ordinateur A, mais en général, j’utilise seulement l’ordinateur B. Quand j’utilise BaoCut sur l’ordinateur B pour la transcription, je veux faire en sorte que l’ordinateur A prenne en charge la partie qui consomme de la puissance de calcul pour la transcription.
À première vue, je me suis dit que c’était une demande intéressante. Mais je n’avais jamais fait ce genre de chose, et je ne savais pas si c’était faisable.
Du coup, ma première étape n’a pas été d’écrire du code tout de suite, mais de faire d’abord une analyse de faisabilité.
1. Analyse de faisabilité
Ne pas faire d’analyse de faisabilité avant de se lancer, c’est vraiment une perte trop fréquente. On finit souvent par travailler pour rien. En plus, même en faisant une analyse, on peut parfois se tromper. Par exemple, il y a quelques jours, j’ai créé un modèle texte local pour aider à découper et aligner. Pendant l’analyse de faisabilité, je me suis dit que ça allait. Une fois terminé, j’ai testé concrètement et j’ai découvert que les résultats étaient très mauvais. Finalement, j’ai tout supprimé, et j’ai perdu plusieurs jours, en consommant beaucoup de tokens… heureusement, c’était “juste” des tokens.
L’analyse de faisabilité comporte généralement deux niveaux :
Un niveau produit : cette fonction a-t-elle une vraie valeur pour les utilisateurs, et correspond-elle à la positionnement de l’application ?
Un niveau technique : est-ce que la fonction est techniquement réalisable, et le coût reste-t-il maîtrisable ?
Ici, côté produit, je pense que cette fonction est utile pour les utilisateurs et qu’elle correspond bien au positionnement du produit. Donc je me suis concentré uniquement sur l’analyse de faisabilité technique.
J’ai donc envoyé la demande initiale à Claude Code, en lui demandant de faire une analyse de faisabilité en tenant compte de l’état du projet (figure 2). Après analyse, il a donné un verdict : c’est faisable, et il a aussi proposé plusieurs solutions (figure 3).
Ces solutions peuvent demander un peu de bagage technique pour mieux être comprises. Après l’avoir lu, j’ai rapidement tiré mes propres conclusions :
La solution 0 et la solution C ne nécessitent pas de modifier le code, mais elles sont trop peu pratiques pour l’utilisateur : il faudrait que l’utilisateur mette en place lui-même un serveur asr.
La solution A a l’air très bien : il suffit d’installer l’application pour lancer son propre service de transcription.
La solution B n’est pas adaptée à Windows.
Donc j’ai décidé d’avancer selon la solution A. En plus, même si la solution 0 n’était pas fiable, le fait qu’elle propose une API http de transcription constitue aussi un bon “bonus”, qu’on peut ajouter en passant.
2. Rédaction du document de conception
Une fois la faisabilité confirmée, et une solution technique préliminaire retenue, je n’ai pas commencé directement à écrire du code. J’ai d’abord rédigé un document de conception.
Ce document de conception est plutôt un mélange entre un document de conception produit et un plan de conception technique : il décrit clairement les besoins, la conception de l’architecture, et même une partie du design UI.
L’objectif est d’aider l’IA à clarifier les technologies nécessaires pour l’implémentation, l’état actuel du projet, et de tout consigner dans un document. Ainsi, lors de la mise en œuvre, on dispose d’une bonne référence, et plus tard, pour la maintenance, on peut aussi s’y référer. Le plus important est que les humains puissent confirmer si la direction est bonne ou non. (voir figure 4)
Bien sûr, j’admets que j’ai “faini” ici : je lui ai dit d’écrire le document puis de passer directement à l’exécution. C’est surtout parce que, d’après ce que j’avais vu, le plan proposé ne posait pas trop de problèmes, et que je fais assez confiance à Fable ; si j’en avais les moyens, j’aurais quand même vérifié davantage.
3. Conception du prototype
Si j’ai fait un prototype avant d’écrire du code, c’est parce qu’il permet de valider la demande à faible coût, et de définir rapidement le design de l’interface et l’interaction. Ici, j’ai déjà installé le skill baoyu-design (github.com/jimliu/baoyu-design), donc il suffit de dire “prototype” pour déclencher l’action automatiquement.
Mon application a une page de prototype dédiée. À chaque fois que j’ajoute ou modifie une fonction, je commence par mettre à jour cette page de prototype.
Grâce au document de conception précédent, la conception du prototype a été relativement fluide. Dès la première version (figure 5), j’obtiens déjà un résultat assez bon : dans la page des paramètres, j’ai ajouté un nouvel écran d’options, qui permet d’activer le service et de découvrir les nœuds.
Notez que dans mon cas, le prototype que j’ai réalisé combine en fait un prototype et un design UI à haute précision : le prototype correspond au design UI. C’est d’ailleurs une des grandes caractéristiques de Claude Design.
Une fois le prototype prêt, il faut encore l’ajuster. À ce moment-là, l’humain doit donner du feedback basé sur le prototype pour que l’agent ajuste. Par exemple, ici, j’ai fait plusieurs itérations. (voir figure 6)
D’abord, j’ai modifié la mise en page en la passant en Tab, afin de séparer l’activation du service et l’accès aux autres nœuds : à mes yeux, ce sont deux scénarios différents. Ensuite, j’ai ajouté des icônes pour afficher l’état du service, ce qui permet de comprendre clairement si le service est démarré ou arrêté via l’icône. (voir figure 7)
Puis j’ai remarqué que l’intégrer dans la page des paramètres n’était pas pratique pour voir l’état du service, alors je l’ai déplacé vers l’interface principale. Finalement, j’ai estimé que c’était suffisamment bon. (figure 8, figure 9)
4. Implémentation
Si vous avez déjà un document de conception et un prototype (design UI), alors demander à l’IA d’écrire le code, pour les agents actuels, c’est quelque chose de très simple.
À ce moment-là, j’utilise généralement /goal pour envoyer le document à Claude Code (Fable 5) afin qu’il fasse l’implémentation. Il réalise les étapes une par une selon les Milestones du document, et il capture aussi des captures d’écran pour valider les résultats. (figure 10, figure 11)
5. Tests et validation
Même si l’agent nous aide à valider, cela ne veut pas dire qu’on peut totalement faire confiance aux résultats de l’IA. Ensuite, il faut quand même exécuter le tout manuellement quelques fois, relever les problèmes, et les communiquer à l’agent pour qu’il fasse des ajustements (figure 12).
Après quelques cycles d’ajustements, on peut finalement dire que ça devient utilisable.
Voici le résultat final (figure 13, figure 14).
Vous voulez savoir si j’ai fait une revue du code ?
Non. Je me suis positionné comme QA : j’ai seulement fait des tests en “boîte noire”. Je fais quand même confiance aux capacités de Fable.
L’origine de cette fonctionnalité vient du fait qu’un internaute m’a laissé un message dans les Issues GitHub (figure 1). Il m’a demandé si je pouvais ajouter à mon application BaoCut, qui fait de la transcription et de la traduction de sous-titres, une fonction de transcription à distance.
En d’autres termes, j’ai deux ordinateurs : l’un est une machine hautes performances A équipée d’une carte graphique Nvidia ; l’autre est juste un ordinateur de bureau B au quotidien. Je veux profiter de la puissance de calcul de l’ordinateur A, mais en général, j’utilise seulement l’ordinateur B. Quand j’utilise BaoCut sur l’ordinateur B pour la transcription, je veux faire en sorte que l’ordinateur A prenne en charge la partie qui consomme de la puissance de calcul pour la transcription.
À première vue, je me suis dit que c’était une demande intéressante. Mais je n’avais jamais fait ce genre de chose, et je ne savais pas si c’était faisable.
Du coup, ma première étape n’a pas été d’écrire du code tout de suite, mais de faire d’abord une analyse de faisabilité.
1. Analyse de faisabilité
Ne pas faire d’analyse de faisabilité avant de se lancer, c’est vraiment une perte trop fréquente. On finit souvent par travailler pour rien. En plus, même en faisant une analyse, on peut parfois se tromper. Par exemple, il y a quelques jours, j’ai créé un modèle texte local pour aider à découper et aligner. Pendant l’analyse de faisabilité, je me suis dit que ça allait. Une fois terminé, j’ai testé concrètement et j’ai découvert que les résultats étaient très mauvais. Finalement, j’ai tout supprimé, et j’ai perdu plusieurs jours, en consommant beaucoup de tokens… heureusement, c’était “juste” des tokens.
L’analyse de faisabilité comporte généralement deux niveaux :
Un niveau produit : cette fonction a-t-elle une vraie valeur pour les utilisateurs, et correspond-elle à la positionnement de l’application ?
Un niveau technique : est-ce que la fonction est techniquement réalisable, et le coût reste-t-il maîtrisable ?
Ici, côté produit, je pense que cette fonction est utile pour les utilisateurs et qu’elle correspond bien au positionnement du produit. Donc je me suis concentré uniquement sur l’analyse de faisabilité technique.
J’ai donc envoyé la demande initiale à Claude Code, en lui demandant de faire une analyse de faisabilité en tenant compte de l’état du projet (figure 2). Après analyse, il a donné un verdict : c’est faisable, et il a aussi proposé plusieurs solutions (figure 3).
Ces solutions peuvent demander un peu de bagage technique pour mieux être comprises. Après l’avoir lu, j’ai rapidement tiré mes propres conclusions :
La solution 0 et la solution C ne nécessitent pas de modifier le code, mais elles sont trop peu pratiques pour l’utilisateur : il faudrait que l’utilisateur mette en place lui-même un serveur asr.
La solution A a l’air très bien : il suffit d’installer l’application pour lancer son propre service de transcription.
La solution B n’est pas adaptée à Windows.
Donc j’ai décidé d’avancer selon la solution A. En plus, même si la solution 0 n’était pas fiable, le fait qu’elle propose une API http de transcription constitue aussi un bon “bonus”, qu’on peut ajouter en passant.
2. Rédaction du document de conception
Une fois la faisabilité confirmée, et une solution technique préliminaire retenue, je n’ai pas commencé directement à écrire du code. J’ai d’abord rédigé un document de conception.
Ce document de conception est plutôt un mélange entre un document de conception produit et un plan de conception technique : il décrit clairement les besoins, la conception de l’architecture, et même une partie du design UI.
L’objectif est d’aider l’IA à clarifier les technologies nécessaires pour l’implémentation, l’état actuel du projet, et de tout consigner dans un document. Ainsi, lors de la mise en œuvre, on dispose d’une bonne référence, et plus tard, pour la maintenance, on peut aussi s’y référer. Le plus important est que les humains puissent confirmer si la direction est bonne ou non. (voir figure 4)
Bien sûr, j’admets que j’ai “faini” ici : je lui ai dit d’écrire le document puis de passer directement à l’exécution. C’est surtout parce que, d’après ce que j’avais vu, le plan proposé ne posait pas trop de problèmes, et que je fais assez confiance à Fable ; si j’en avais les moyens, j’aurais quand même vérifié davantage.
3. Conception du prototype
Si j’ai fait un prototype avant d’écrire du code, c’est parce qu’il permet de valider la demande à faible coût, et de définir rapidement le design de l’interface et l’interaction. Ici, j’ai déjà installé le skill baoyu-design (github.com/jimliu/baoyu-design), donc il suffit de dire “prototype” pour déclencher l’action automatiquement.
Mon application a une page de prototype dédiée. À chaque fois que j’ajoute ou modifie une fonction, je commence par mettre à jour cette page de prototype.
Grâce au document de conception précédent, la conception du prototype a été relativement fluide. Dès la première version (figure 5), j’obtiens déjà un résultat assez bon : dans la page des paramètres, j’ai ajouté un nouvel écran d’options, qui permet d’activer le service et de découvrir les nœuds.
Notez que dans mon cas, le prototype que j’ai réalisé combine en fait un prototype et un design UI à haute précision : le prototype correspond au design UI. C’est d’ailleurs une des grandes caractéristiques de Claude Design.
Une fois le prototype prêt, il faut encore l’ajuster. À ce moment-là, l’humain doit donner du feedback basé sur le prototype pour que l’agent ajuste. Par exemple, ici, j’ai fait plusieurs itérations. (voir figure 6)
D’abord, j’ai modifié la mise en page en la passant en Tab, afin de séparer l’activation du service et l’accès aux autres nœuds : à mes yeux, ce sont deux scénarios différents. Ensuite, j’ai ajouté des icônes pour afficher l’état du service, ce qui permet de comprendre clairement si le service est démarré ou arrêté via l’icône. (voir figure 7)
Puis j’ai remarqué que l’intégrer dans la page des paramètres n’était pas pratique pour voir l’état du service, alors je l’ai déplacé vers l’interface principale. Finalement, j’ai estimé que c’était suffisamment bon. (figure 8, figure 9)
4. Implémentation
Si vous avez déjà un document de conception et un prototype (design UI), alors demander à l’IA d’écrire le code, pour les agents actuels, c’est quelque chose de très simple.
À ce moment-là, j’utilise généralement /goal pour envoyer le document à Claude Code (Fable 5) afin qu’il fasse l’implémentation. Il réalise les étapes une par une selon les Milestones du document, et il capture aussi des captures d’écran pour valider les résultats. (figure 10, figure 11)
5. Tests et validation
Même si l’agent nous aide à valider, cela ne veut pas dire qu’on peut totalement faire confiance aux résultats de l’IA. Ensuite, il faut quand même exécuter le tout manuellement quelques fois, relever les problèmes, et les communiquer à l’agent pour qu’il fasse des ajustements (figure 12).
Après quelques cycles d’ajustements, on peut finalement dire que ça devient utilisable.
Voici le résultat final (figure 13, figure 14).
Vous voulez savoir si j’ai fait une revue du code ?
Non. Je me suis positionné comme QA : j’ai seulement fait des tests en “boîte noire”. Je fais quand même confiance aux capacités de Fable.