La pile de livraison IA exacte qu’utilise un CPO pour réduire les retravaux de 25 %
L'IA peut générer du code en quelques secondes. Mais sans architecture, elle aide simplement à livrer la mauvaise chose plus rapidement. Dans cette interview, un CPO et Directeur de l'Ingénierie partage le système IA axé sur l'architecture qu'il utilise pour diviser par deux le temps de prototypage, réduire les retravaux de 25 % et concevoir des garde-fous pour un cycle de développement logiciel piloté par l'IA.
Yurii Lozinskyi
Le CPO et Directeur de l'Ingénierie chez Verysell
Leadership en IA: L'IA fait passer la gestion de projet de la coordination à la conception de systèmes, réduisant les tâches manuelles grâce à l'intégration de l'IA.
Rôle de l'architecture: Une architecture robuste prévient le chaos de livraison IA, alignant le travail généré par l'IA sur les standards de qualité et les objectifs.
Efficacité du prototypage: Une IA guidée par l’architecture réduit les coûts, accélérant le passage de l’idée au modèle fonctionnel en quelques jours.
Valeur de l'ingénieur: L'IA augmente la valeur des ingénieurs seniors en renforçant la conception architecturale et en réduisant le codage aléatoire.
Évolution de la gestion de projet: Les futurs rôles de gestion de projet exploiteront l'IA pour la coordination, en se concentrant davantage sur la conception, la stratégie et la gouvernance.
Yurii Lozinskyi est le CPO et Directeur de l’ingénierie chez Verysell AI, où il dirige la livraison de l’IA. Fort de 25 ans d’expérience, transformer les initiatives logicielles et d’IA en résultats métier mesurables est son quotidien.
Nous nous sommes donc entretenus avec lui pour découvrir comment il s’y prend. Voici ce qu’il nous a confié.
S’assurer que l’IA n’est pas juste un gadget tape-à-l’œil
Je suis un responsable produit et ingénierie qui évolue à la croisée des systèmes d’IA, de la livraison logicielle et de la réalité business. J’ai passé plus de 15 ans à livrer des solutions dans la banque, l’assurance, les plateformes ITSM/MSP, le retail et la santé. Et d’une manière ou d’une autre, je reviens toujours à l’assurance, car c’est là que la complexité et l’impact sont les plus forts.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
En ce moment, je ne gère plus les projets au sens traditionnel. Je conçois comment les projets devraient fonctionner et j’essaie de rester impliqué lors de la livraison. Cela signifie travailler sur les modèles opérationnels, les schémas de livraison alimentés par l’IA et les feuilles de route d’hypothèses et validation, sur plusieurs équipes et clients.
En résumé, mon travail consiste à m’assurer que l’IA n’est pas juste un gadget à côté, mais au cœur de la définition, de l’exécution et de la gouvernance du travail de bout en bout.
Comment l’IA fait passer la gestion de projet de la coordination à la conception de systèmes
Le pilotage de la livraison bascule de la gestion de planning à la conception de systèmes. Je passe beaucoup moins de temps en réunions de suivi ou à rédiger manuellement des livrables que les machines produisent désormais en quelques secondes. Si l’IA peut m’aider à écrire la première version d’un plan ou d’un résumé, je la laisse volontiers faire.
Beaucoup de chefs de projet passent encore aujourd’hui 40–60% de leur temps à courir derrière le statut, à faire des reportings manuels, à identifier les risques élémentaires et à faire circuler l’information entre outils et interlocuteurs. Dans un environnement enrichi par l’IA, cela tombe sous 10–15%, car des agents intégrés gèrent les mises à jour, les synthèses, les rappels et les escalades simples entre Jira/Linear, Slack/Teams et la documentation.
La contrepartie, c’est que mon rôle monte d’un cran : je me préoccupe des contraintes, des critères d’acceptation, des garde-fous, et des boucles de rétroaction. En d’autres termes, je conçois les « rails » sur lesquels humains et agents IA fonctionnent.
J’ai un biais pour l’architecture : j’utilise le modèle C4 et ISO/IEC 25010 comme cadre pour les documents de vision d’architecture, puis je m’en sers comme prompts. C’est la partie amusante : traiter l’architecture comme une API pour l’IA. Vos documents d’architecture ne prennent pas la poussière, ils servent de carburant à un cycle de développement logiciel (SDLC) alimenté par l’IA. Plus à ce sujet dans un instant.
L’IA permet d’aller très vite en toute simplicité, donc mon rôle est de veiller à ce que la rapidité suive la bonne direction. Au lieu de demander « Qui fait quoi cette semaine ? », je me demande « Notre système rend-il difficile de livrer la mauvaise chose rapidement ? »
L’IA permet d’aller très vite en toute simplicité, donc mon rôle est de veiller à ce que nous allions vite dans la bonne direction.
Pourquoi l’architecture évite le chaos de livraison provoqué par l’IA
J’apprécie le C4, l’ISO 25010 et les documents de vision d’architecture parce qu’ils constituent une colonne vertébrale pour intégrer l’IA dans la livraison. Sans cette structure, l’IA peut vite devenir une nouvelle source de chaos dans le delivery.
Concrètement :
- C4 offre à l’IA une carte du système. Au lieu de « Écris juste du code », on peut dire : « Dans ce contexte et ce conteneur, via ces interfaces, applique ce changement. » Cela oblige le travail généré par l’IA à rester dans des limites architecturales claires.
- L’ISO 25010 définit ce qui est "bon" au-delà de "ça compile". Nous traduisons ses attributs de qualité en scénarios concrets — performance, sécurité, maintenabilité, fiabilité — puis nous les intégrons dans les prompts et critères d’acceptation. L’IA génère alors des PoCs et des tests en phase avec des attentes de qualité explicites, pas seulement sur la fonctionnalité.
- Les documents de vision d’architecture rassemblent tout. Ils relient les objectifs métier, les vues C4 et les scénarios de qualité à la ISO dans un seul récit, lisible à la fois pour les humains et l’IA. Pour les humains, ils servent d’artefact de synchronisation. Pour l’IA, ils fournissent la source contextuelle principale pour générer code, tests et documentation.
Ensemble, ils transforment l’IA d’un super-pouvoir aléatoire en un composant maîtrisé du SDLC enrichi par l’IA, avec des limites claires, de la traçabilité et une compréhension commune de ce que nous voulons construire.
Comment réduire drastiquement le coût de l’erreur grâce à des prototypes d’IA guidés par l’architecture
Voici un exemple. Nous avions une fonctionnalité d’appariement par IA qui, dans « l’ancien monde », aurait pris environ deux semaines pour passer de l’idée à un prototype cliquable.
Au lieu de commencer par des tickets Jira et des prompts improvisés, nous avons d’abord rédigé un court document de vision d’architecture. Nous avons dessiné des diagrammes de type C4 : contexte système, conteneurs impliqués, composants clés, ainsi qu’une poignée de scénarios de qualité inspirés d’ISO-25010 (par exemple, latence, auditabilité, gestion des erreurs).
Puis nous avons traité cette architecture comme une API pour l’IA :
- Nous avons injecté le document de vision et des extraits C4 dans notre assistant de codage, comme seule source de vérité pour les prompts.
- Nous lui avons demandé de générer le squelette, la logique du flux principal et les premiers tests à l’intérieur des conteneurs et interfaces spécifiés.
Vous ne demandez pas à l’IA de « Me coder quelque chose » mais « Implémente cette interaction spécifique avec ces contraintes et ces attributs de qualité. » C’est un tout autre jeu. Et cela nous a permis d’obtenir un POC cohérent en quelques jours au lieu de tout coder à la main depuis zéro.
Des ingénieurs ont toujours relu et corrigé, mais :
- Le temps entre « on devrait essayer ça » et « les parties prenantes peuvent tester un prototype fonctionnel » est passé d’environ dix jours ouvrables à trois ou quatre. C’est presque déloyal à quel point on arrive vite à un prototype crédible quand l’architecture structure les prompts au lieu de simples envies vagues.
- Nous avons observé 20 à 25 % de cycles de reprise en moins, car le code généré par l’IA respectait déjà les limites et les schémas définis dans l’architecture.
- Les ingénieurs signalaient passer environ 20 % de temps en moins sur le code passe-partout et le code de liaison, supprimant de fait tout un rôle distinct « d’ingénieur d’intégration ».
- La couverture de tests pour cette partie était plus élevée dès le premier passage, car l’assistant faisait des suggestions de tests pour cas limites à partir des scénarios de qualité documentés, que nous n’aurions probablement pas écrits aussi tôt.
En d’autres termes, une fois l’architecture rendue explicite et structurée, l’IA a cessé de se comporter comme un simple autocompléteur astucieux pour agir comme un ingénieur junior qui comprend réellement la cartographie du système, documente parfaitement et ne dort jamais.
Et surtout, cela a fait s’effondrer le coût de l’erreur — et c’est exactement ce que vous voulez dans des domaines complexes.
Pourquoi l’IA rend les ingénieurs seniors encore plus précieux
Contrairement à ce qu’on pourrait croire, l’IA rend les ingénieurs seniors encore plus précieux, et non l’inverse.
Si vous connectez l’IA à une architecture faible et un manque de discernement, vous obtenez un chaos accéléré. Sous la supervision d’un architecte solide, un seul senior peut explorer cinq designs avant le déjeuner et avoir encore du temps pour discuter avec les parties prenantes.
L’IA comble certains écarts de compétences, mais elle amplifie surtout la différence entre du code aléatoire et un travail de conception intentionnelle.
Si vous connectez l’IA à une architecture faible et un manque de discernement, vous obtenez un chaos accéléré. Sous la supervision d’un architecte solide, un seul senior peut explorer cinq designs avant le déjeuner et avoir encore du temps pour discuter avec les parties prenantes.
Adieu l’analyste métier — bienvenue à l’expert du domaine.
Quelles tâches de livraison doivent être automatisées en priorité avec l’IA
Actuellement, les parties du travail de livraison les plus mûres pour l’automatisation sont les activités « riches en contexte, répétitives, peu valorisantes » :
- Comme mentionné précédemment, génération de code PoC et de tests à partir de documents de vision architecturale et de spécifications C4/ISO 25010
- Rédaction des journaux de décisions, options de conception et listes de risques
- Transformer des fils Slack désordonnés en quelque chose que vous pourrez relire sans pleurer
L’IA excelle dans la suggestion ; elle est terrible pour assumer la responsabilité. Voici les domaines sur lesquels les humains gardent encore pleinement la main :
- Définir le problème
- Faire des arbitrages entre risques et rapidité
- Gérer les contraintes réglementaires et éthiques
- Décider quand "techniquement correct" n'est pas la bonne chose à livrer
Le point idéal actuellement consiste à accélérer les premières phases de découverte et les boucles de conception. Les agents sont doués pour transformer une spécification cohérente en chemins plausibles. Ils ne saisissent pas encore quand un chemin est politiquement, éthiquement ou stratégiquement erroné, donc les humains restent entièrement responsables.
Pourquoi les PM doivent prioriser les boucles de retour d'information plutôt que la cérémonie
La gestion de projet traditionnelle contient souvent beaucoup de rituels sans véritable objectif. Je m’en éloigne pour adopter des systèmes qui privilégient le feedback à la cérémonie.
Concrètement, cela signifie :
- Moins de plans monolithiques ; plus de petites hypothèses testables
- Moins de grandes réunions de suivi ; plus de mises à jour asynchrones auto-résumées par l’IA
- Moins de cahiers des charges volumineux ; davantage de documents de vision architecturale vivants sur lesquels humains et IA peuvent agir
Nous tenons toujours compte des dates, des budgets et des risques. Mais nous laissons l’IA gérer la gestion administrative afin que les humains puissent se concentrer sur la conception, les décisions et la réalité des parties prenantes.
L’ironie, c’est qu’en supprimant la moitié du rituel, les gens respectent davantage la structure restante.
L’ironie, c’est qu’en supprimant la moitié du rituel, les gens respectent davantage la structure restante.
Comment les intégrations IA fluidifient la livraison de projet dans GitHub et CI/CD
D’un point de vue technique, « passer en mode léger » signifiait connecter l’IA directement au dépôt et aux environnements, pas seulement ajouter un tableau de bord de plus.
Concrètement, nous avons intégré un assistant de codage IA appelé Codex à nos dépôts GitHub et à notre pipeline CI/CD. Les ingénieurs travaillent dans leur IDE habituel, mais l’assistant peut voir la structure du dépôt et tout faire, comme dit ci-dessus, à partir de diagrammes d’architecture type C4 et d’un document de vision architecturale. Pour environ 20 USD par ingénieur et par mois, c’est moins cher que pratiquement n’importe quel autre levier de productivité.
De plus, nous utilisons une automatisation du déploiement simple (pipelines basés sur GitHub) qui nous permet de déployer les évolutions assistées par IA dans un environnement de prototypage dédié en un seul clic.
Même la génération des prompts est partiellement automatisée : un modèle GPT de dernière génération (GPT-5.2) peut générer des prompts structurés pour des outils comme Eraser à partir de nos documents de vision architecturale.
L’essentiel, c’est que tout cela repose sur des garde-fous classiques : les ingénieurs relisent toujours chaque pull request, le CI/CD tourne toujours, et rien ne part en production sans validation humaine. L’IA accélère la partie répétitive ; les humains restent responsables de la conception, des risques et du dernier mot.
Pourquoi les prototypes IA redéfinissent les rituels de livraison
Toutes ces évolutions ont profondément modifié nos rituels de livraison.
Définir le périmètre, c’était auparavant : « parlons-en pendant des heures puis écrivons un document que personne ne lira ». Aujourd’hui, c’est : « allons vite vers un prototype et débattons sur quelque chose d’interactif ».
Nous partons d’un objectif de haut niveau, nous le formalisons dans un document de vision architecturale, nous dessinons les vues C4, puis utilisons l’IA pour générer un PoC ou au moins une maquette réaliste. Soudain, tout le monde a un avis — car il y a enfin quelque chose de concret à commenter.
En d’autres termes, nous obtenons l’alignement autour du comportement, pas de listes à puces.
Nous validons en combinant tests générés par l’IA (idéaux pour la couverture et la régression) et scénarios conçus par des humains (excellents pour le jugement et les cas limites insolites).
Et nous déplaçons la gestion de l'exécution de « l'attribution de tâches » vers la « conception de flux » : qui — ou quoi — doit voir cette partie du travail ensuite, et avec quel contexte ?
À quoi ressemble une pile de livraison IA simple
Ma pile est affirmée mais reste simple.
Pour l’architecture et l’alignement, j’utilise des schémas inspirés du style C4 et des Documents de Vision d'Architecture, réalisés dans des outils comme Eraser. Cela permet d’itérer facilement devant des humains puis d’intégrer ces éléments à l’IA.
Pour les spécifications, je privilégie les documents textuels, qui décrivent l’intention, les contraintes et les attributs de qualité de façon intelligible pour un LLM.
Côté ingénierie, j’utilise des IDE modernes avec une forte assistance IA et des outils comme Claude Code et Codex pour générer des implémentations de PoC et des tests directement à partir de ces artefacts d’architecture. Je n’ai volontairement pas confié de fonctionnalités de production complètes à l’IA. Elle rédige, établit des squelettes, propose. Des ingénieurs — des vrais — décident toujours de ce qui finit en production.
Fait important : chacun de ces outils a cessé d’être une île. Ils sont tous désormais connectés dans un SDLC dopé à l’IA : exigences, architecture, codage, tests et même gouvernance profitent d’une couche d’assistance.
En pratique, je m’attends à ce que ce changement libère environ 18 à 25 % de gains de productivité sur toute la chaîne de livraison. Mais soyez clair : ce chiffre dépend fortement du point de départ de l’organisation — maturité, processus existants et discipline architecturale.
Comment l'adoption sélective d’outils améliore la livraison IA
Au cours de l’année écoulée, nous avons délibérément commencé à remplacer et à tester des outils, au lieu d’essayer de tout « rendre compatible avec l’IA » d’un seul coup.
Côté livraison, nous avons introduit Miro pour des roadmaps légers et des ateliers d’architecture, mais uniquement à titre pilote sur quelques petits projets. L’objectif était d’évaluer dans quelle mesure les tableaux Miro, associés à des synthèses générées par l’IA, pouvaient remplacer de longs diaporamas et des documents d’alignement manuels. Les premiers retours sont positifs, mais il reste à valider et à généraliser l’approche avant qu’elle ne devienne la norme.
Pour la documentation et les spécifications, nous avons conservé un outil centré sur le texte pour les Documents de Vision d'Architecture. Nous y avons ajouté une assistance IA via de très légers GPT personnalisés — reléguant discrètement à la retraite de volumineux documents statiques de spécification que nous ne maintenions plus et qui ne se prêtaient pas bien aux prompts.
Je l’ai déjà abordé plus haut, mais côté ingénierie, nous avons ajouté Codex comme assistant de développement IA, intégré à notre dépôt Git et à notre pipeline CI pour la génération de squelettes PoC et de tests, tout en conservant nos IDE et outils de déploiement existants. En d’autres termes, nous ne démontons pas encore toute la pile. Nous superposons l’IA là où elle apporte un vrai gain, en commençant par des pilotes contrôlés avant tout déploiement à grande échelle.
Nous ne démontons pas encore toute la pile. Nous superposons l’IA là où elle apporte un vrai gain, en commençant par des pilotes contrôlés avant tout déploiement à grande échelle.
Où va la gestion de projet dans les cinq prochaines années
D’ici cinq ans, « gestionnaire de projet » comme rôle purement de coordination aura quasiment disparu dans la tech. Le travail existera toujours, mais des agents IA intégrés prendront en charge la majeure partie de la coordination, du suivi et du reporting au sein de vos outils.
Les humains qui étaient auparavant appelés chefs de projet évolueront soit vers la conception de SDLC IA et de modèles de gouvernance, soit vers des fonctions produit ou stratégie.
Les tableaux de bord de performance des PM délaisseront l’axe « dans les délais / dans le budget » au profit d’un petit ensemble de métriques système qu’ils influencent activement : délai de mise en œuvre des changements, taux de défauts échappés, latence des décisions, cadence des expérimentations, et notes de confiance des parties prenantes. L’IA fera la plupart des comptes ; les PM seront redevables de l’évolution de ces indicateurs – non parce qu’ils traitent plus de tickets, mais parce qu’ils conçoivent de meilleures façons de travailler.
Les PM qui se limitent à « gérer le statut » seront progressivement remplacés par des bots capables de le faire 24/7 et de mettre à jour six tableaux de bord d’un seul coup, sans broncher.
Pourquoi les chefs de projet devraient considérer l’IA comme un coéquipier, pas simplement un sujet à apprendre
Mon conseil : cessez d’essayer de “comprendre l’IA” comme s’il s’agissait d’un nouveau framework et traitez-la comme un nouveau type de coéquipier avec des forces particulières et ses propres zones d’ombre. Nous appelons la nôtre, en plaisantant, "gptBuddy".
Choisissez un flux de travail, une équipe et une métrique qui comptent, puis lancez une expérience impitoyable. Si vous ne constatez pas d’amélioration significative, modifiez la configuration ou arrêtez.
La vraie valeur de l’IA paraît ennuyeuse vue de l’extérieur. Ce n’est pas ce à quoi s’attendent les amateurs de science-fiction. Ce sont plutôt des succès discrets mais cumulatifs : génération de tests, nettoyage de documentation, création de structures, exploration des variantes, etc.
En même temps, levez les yeux de vos outils et projetez à quoi pourrait ressembler un cycle de développement logiciel (SDLC) alimenté par l’IA pour votre organisation. Si vous ne le faites pas, quelqu’un d’autre le fera — et ses équipes iront plus vite, avec moins de réunions et moins de tensions.
Cessez d’essayer de “comprendre l’IA” comme s’il s’agissait d’un nouveau framework et traitez-la comme un nouveau type de coéquipier avec des forces particulières et ses propres zones d’ombre.
À suivre
Vous pouvez suivre Yurii Lozinskyi sur LinkedIn et Dev.to où il partage son expertise technique en matière d’IA, d’ingénierie, de produit et de livraison. Et découvrez Verysell AI.
D’autres interviews d’experts arrivent bientôt sur The Digital Project Manager !
