Un expert produit partage le flux de travail de codage par intuition qui remplace les transmissions aux équipes d’ingénierie

Anton Ingachev

Fondateur de Mini Apps Builder

Anton Ingachev

Anton Ingachev explique comment le codage par intuition permet aux chefs de produit de concevoir et de déployer directement des fonctionnalités, en réduisant les transmissions aux équipes d’ingénierie tout en maintenant la revue technique dans le flux de travail.

Key Takeaways

Déploiement plus rapide: L’IA permet aux responsables produit de concevoir directement des fonctionnalités simples, supprimant les transmissions aux équipes d’ingénierie et accélérant les mises en production avec de petites équipes.

Le contexte est essentiel: Un meilleur contexte de projet aide l’IA à produire plus rapidement des contenus de meilleure qualité, tandis qu’un contexte limité génère des résultats faibles et peu fiables.

Conception du flux de travail: Les équipes produit peuvent utiliser l’IA dans le développement, la traduction, la création de contenu, la recherche, les tests et la documentation des mises en production.

Supervision humaine: Les travaux générés par l’IA nécessitent toujours des consignes claires, une revue, des tests et un jugement d’expert avant d’atteindre les clients.

Expérimenter d’abord: Les responsables doivent réévaluer les processus existants, puis tester de manière sélective, car l’adoption efficace de l’IA dépend des contraintes propres à chaque produit.

Anton Ingachev est le fondateur de Mini Apps Builder, une plateforme sans code permettant de créer des applications Telegram, dont il dirige le produit. Auparavant, il a occupé plusieurs postes de CPO et de directeur produit.

Nous avons échangé avec Anton pour comprendre comment il élimine les transmissions entre équipes d'ingénierie en codant lui-même de petites fonctionnalités avec le « vibe coding ». Voici ce qu'il nous a raconté.

Se tourner vers l'IA par nécessité

Se tourner vers l'IA par nécessité

Je travaille dans le produit depuis plus de dix ans — fintech, plateformes d'échecs, blockchain, technologies de la santé. J'ai été CPO à deux reprises et directeur produit une fois.

Mon parcours dans l'IA a commencé par un besoin concret, et non par une stratégie. Il y a environ un an et demi, j'ai cofondé Mini Apps Builder — une plateforme B2B2C sans code permettant de créer des applications Telegram. En tant que CPO non ingénieur, je devais livrer rapidement des fonctionnalités sans attendre un cycle de développement complet. C'est à ce moment-là que j'ai commencé à utiliser Claude Code et Cursor quotidiennement, non seulement pour la documentation ou le prototypage, mais aussi pour le travail en production.

Pour démontrer tout son potentiel, j'ai créé seul un produit prêt pour la production — architecture, backend, frontend, tout — à l'aide d'outils d'IA, sans équipe d'ingénierie. C'est à ce moment-là que je suis passé de « j'utilise l'IA pour travailler plus vite » à « je peux créer et livrer moi-même de vrais produits ».

Désormais, j'applique la même approche au sein de Mini Apps Builder : je développe directement certaines fonctionnalités au lieu de me contenter de les spécifier pour les ingénieurs.

Mon parcours n'a donc pas été : « J'ai lu des articles sur la transformation par l'IA et j'ai décidé de la diriger. » J'avais plutôt besoin d'avancer rapidement sans grande équipe ; l'IA a rendu cela possible, et je réfléchis maintenant différemment à la stratégie produit — chaque décision de la feuille de route inclut désormais la question suivante : « L'IA peut-elle réaliser cette étape, ou peut-elle seulement la soutenir ? »

More Articles

Comment l'IA remplace l'ancien modèle de transmission dans les flux de travail produit

Pendant des années, j'ai pensé que le travail d'un PM s'arrêtait aux spécifications. On rédige les exigences, mais on ne touche pas au code — c'est le travail de l'ingénieur. Franchir cette limite semblait déplacé.

C'est la principale chose que l'IA a changée dans le monde du produit. Désormais, je m'occupe moi-même des fonctionnalités simples. Je les développe avec Claude Code et les mets directement en production, sans attendre la disponibilité de l'équipe d'ingénierie.

Nous pouvons ainsi supprimer toute une étape de transmission. Au lieu de passer des spécifications à la revue d'ingénierie, puis au développement et à l'assurance qualité, je développe et teste souvent directement.

Notre cycle de livraison atteint désormais deux ou trois fonctionnalités mises en production par semaine avec une équipe de deux personnes — sur le site web, le tableau de bord marchand, l'application miniature Telegram elle-même et notre panneau d'administration interne. Ce rythme ne serait pas possible avec l'ancien modèle de transmission.

Cela a également changé ma façon de penser la structure de l'équipe. La contrainte n'est plus « Combien d'ingénieurs avons-nous ? », mais plutôt « Avec quelle précision puis-je spécifier ce que je veux ? »

Un flux de développement de fonctionnalités assisté par l'IA

Voici à quoi ressemble le développement d'une fonctionnalité :

  1. Je décris la tâche à un modèle haut de gamme comme Claude Code. J'indique ce qui me plaît, ce qui ne me plaît pas, le problème que nous cherchons à résoudre, ainsi que ce qui ne doit pas être oublié ou détérioré. Je fournis des références — parfois celles de concurrents directs, mais pas toujours.
  2. Le modèle produit un plan détaillé. Je le lis. Si nécessaire, je le modifie ou je le remets en question.
  3. Je demande à Claude d'implémenter le plan dans le code.
  4. Je crée une PR, qui passe par des contrôles automatisés avant d'être attribuée au CTO.
  5. Si tout est correct, le CTO l'intègre dans l'environnement de développement, puis je la teste dans le produit.
  6. Si quelque chose ne va pas, le CTO laisse des commentaires, je demande au modèle de les corriger et le processus recommence.
  7. Si le résultat est très éloigné de ce qui est attendu, je discute avec le CTO de la manière d'améliorer les instructions données au LLM, puis je recommence.
  8. Après les tests dans l'environnement de développement, nous déployons en production.
Anton Ingachev

Les réflexions d'Anton

J’indique ce qui me plaît, ce qui ne me plaît pas, le problème que nous cherchons à résoudre, ainsi que ce qui ne doit pas être oublié ou détérioré.

Où l'IA peut être appliquée dans les flux de travail produit

Où l’IA peut être appliquée dans les flux de travail produit

Les principaux outils d’IA que j’utilise sont Claude Code, Codex, Cursor, Gamma, Midjourney et Figma Agent. Voici d’autres façons dont j’utilise l’IA dans les flux de travail produit, ainsi que certains de ses avantages :

  1. L’intégralité de notre produit — interfaces, blog, centre d’aide, articles sur les mises à jour du produit — est traduite en 20 langues presque en temps réel, en un seul clic.
  2. Les articles de blog rédigés par un LLM ont presque doublé notre trafic issu des recherches — et leur rédaction prend une fraction du temps.
  3. En tant que chef de produit, l’IA m’aide à remettre plus facilement en question mes propres idées — je peux lui demander de trouver des données qui les étayent ou les réfutent.
  4. La rédaction des notes de version n’est plus un problème, puisque l’IA s’en charge presque automatiquement.

Honnêtement, je ne peux pas citer un domaine où l’IA n’est d’aucune aide. Presque partout, son utilisation apporte un avantage évident. Oui, les humains doivent vérifier ses résultats, les ajuster et l’entraîner, mais dès lors qu’un objectif est clairement défini et que l’on comprend comment l’atteindre avec l’IA, le processus s’améliore.

Pourquoi l’IA a besoin d’un contexte approprié avant d’être intégrée aux flux de travail

Lorsqu’il s’agit d’IA, le contexte est essentiel.

Auparavant, je rédigeais des articles de blog à partir du brief d’un spécialiste SEO. Cela me prenait deux à trois heures. Ensuite, j’ai chargé le contexte du projet dans un LLM et je lui ai directement transmis le brief — désormais, les articles prennent 5 à 7 minutes. Et comme je l’ai indiqué plus haut, leur qualité est supérieure, ce qui a entraîné un doublement du trafic.

Lorsqu’il s’agit d’IA, le contexte est essentiel…Quel que soit le flux de travail, investissez dans la mise à disposition du contexte pour vos outils d’IA !

Anton IngachevFondateur de Mini Apps Builder
Share This Quote on:

Mais lorsque j’ai demandé au spécialiste SEO de les rédiger avec l’IA, j’ai été surpris par la médiocrité des résultats. La raison ? Son LLM disposait de beaucoup moins de contexte sur le projet que le mien.

Quel que soit le flux de travail, investissez dans la mise à disposition du contexte pour vos outils d’IA !

Pourquoi les responsables produit doivent repenser certains flux de travail produit, mais pas nécessairement tous

Pourquoi les responsables produit doivent repenser certains flux de travail produit, mais pas nécessairement tous

Mon conseil ? Intégrez dès maintenant l’IA à la plupart de vos processus. Nous ne sommes plus en 2022 ; sa valeur est désormais évidente. L’IA est indispensable.

Les responsables produit devraient réévaluer chaque processus et chaque outil auparavant considérés comme optimaux. Mais cela ne signifie pas nécessairement qu’il faut tous les repenser avec l’IA. Vous devez comprendre les limites de l’IA, vos propres forces et faiblesses, le produit sur lequel vous travaillez, les budgets, etc.

La configuration sera différente pour chaque projet spécifique. Tout est flexible. Et il n’existe pas de bonnes pratiques établies. Cela complique les choses.

La seule façon de trouver la solution adaptée à votre produit consiste à expérimenter concrètement.

Anton Ingachev

Les réflexions d’Anton

Mon conseil ? Intégrez dès maintenant l’IA à la plupart de vos processus. Nous ne sommes plus en 2022 ; sa valeur est désormais évidente. L’IA est indispensable.

Suivez son travail

Vous pouvez suivre le travail d’Anton Ingachev sur LinkedIn et GitHub. Découvrez également Mini Apps Builder.

D’autres entretiens avec des experts sont à venir sur The CPO Club !

You may also like