Construire avec l’IA est facile. Construire et livrer en équipe avec l’IA ne l’est pas

La loi de Conway n’est pas une suggestion. C’est un avertissement.

Toute organisation qui conçoit un système produira un design qui reflète sa propre structure de communication.

— Melvin Conway, 1968

Pendant la majeure partie de l’histoire du logiciel, cela a été un problème lent. Les structures organisationnelles et la culture se figent au fil des années. Vous aviez le temps de remarquer, même si vous agissiez rarement.

Puis l’IA est arrivée — et l’accumulation est passée de lente à instantanée.

Ce schéma est toujours apparu dans la manière dont les organisations ont historiquement construit des logiciels. La structure centralisée d’Apple — matériel et logiciel sous une direction unifiée — a produit des produits intégrés et un écosystème fermé qui reflète cette hiérarchie encore aujourd’hui. L’importante machine juridique et de conformité d’Oracle a donné naissance à des logiciels axés sur les contrats d’entreprise et la gestion des risques, au détriment de l’expérience utilisateur. Ce ne sont pas des échecs de conception. Ce sont des caractéristiques organisationnelles, fidèlement reproduites dans le code depuis des décennies.

La différence aujourd’hui, c’est la rapidité. L’IA ne change pas la dynamique sous-jacente — elle élimine simplement le délai qui la cachait.

Nous avons affronté ce défi en travaillant avec un client qui adoptait le "vibe coding" dans son processus de découverte et de développement produit.

Imaginez que vous examinez un prototype que quelqu’un d’autre a réalisé hier. Vous évaluez un outil présenté comme une révolution pour le poste et peut-être pour tout le secteur. Mais vous découvrez un chiffre dans un graphique de tableau de bord. Il paraît incorrect. Ou peut-être est-il juste. L’analyse semble complexe, mais est-elle exacte, ou même pertinente ? Voilà le vrai problème — et ce n’est pas seulement une question de données. C’est une question d’équipe.

Toboggan Labs est intervenu pour aider un client à concevoir un agent IA d’analyste financier dans une plateforme d’intelligence d’affaires de nouvelle génération. Le fondateur avait à la fois l’expertise métier et la vision : de petites équipes financières sous-exploitées, noyées sous Excel, prenant des décisions des semaines trop tard parce que le bon chiffre nécessitait de rechercher des données dans trop d’endroits. Nous avions utilisé Lovable pour des prototypes rapides, de vraies données clients, et une équipe d’ingénierie compétente.

Les premières démonstrations étaient réellement impressionnantes — du genre à vous faire penser que vous êtes plus avancé que vous ne l’êtes réellement.

Ce que nous avons manqué, c’est ce à quoi je pense désormais dans chaque projet IA : ces outils n’accélèrent pas seulement ce qui fonctionne. Ils amplifient tout — y compris ce qui ne fonctionne pas.

La dysfonction n’était pas évidente au début. L’équipe s’était séparée en deux mondes — un environnement de prototype “vibe-coded” et une base de code production qui s’en éloignait progressivement. Chaque transfert entre les deux nécessitait une traduction lente, imparfaite et dépendante de connaissances métier que personne dans l’équipe technique ne possédait.

Dans la plupart des solutions d’intelligence d’affaires, la juste manière de calculer un indicateur dépend de sa définition, du groupe de référence auquel on le compare, et des nuances conservées dans l’esprit de praticiens aguerris.

Nous avions construit l’infrastructure, la gestion multi-locataires, et les couches de calcul d’indicateurs avant même d’établir, avec le client présent, à quoi ressemblait le "correct" ou le "suffisamment bon". Nous construisions pour l’échelle avant d’avoir terminé de construire pour l’apprentissage. Et comme nous avancions très vite, cet écart s’est accumulé discrètement pendant des mois.

L’IA n’a créé aucun de ces problèmes. Mais elle les a rendus plus rapides et plus visibles. Un tableau de bord produit en “vibe coding” paraît prêt en quelques jours. Cette rapidité masquait tout ce que nous n’avions pas encore résolu. Résultat : un mois pour transformer un prototype en quelque chose que le client pouvait réellement valider. Pas parce que l’ingénierie était difficile — parce que chaque étape exigeait un jugement qui n’était pas inclus dans le processus.

Quand le projet s’est arrêté et que l’équipe s’est réinitialisée, le principal changement n’était pas l’outillage. C’était le fait que l’expert métier était enfin au centre du processus, et non en aval. Le fondateur pouvait avoir une conversation avec un investisseur ou un client le lundi et nous pouvions tester quelque chose dès le mercredi. Les checkpoints ont remplacé la planification des sprints : plus “qu’avons-nous livré” mais “qu’avons-nous appris à cette date”. Le délai pour une démonstration à un investisseur ne nous disait pas combien de temps prendrait chaque tâche — il indiquait ce qu’il fallait prioriser et ce qu’il fallait éliminer en premier.

Mon propre rôle de Product Designer a évolué de façons que j’explore encore. Moins de temps à concevoir des fonctionnalités, plus à concevoir comment l’équipe fonctionne, et comment favoriser cette boucle d’apprentissage rapide. Développer des modèles de projets Lovable avec les bonnes pratiques d’ingénierie déjà intégrées, afin que les prototypes ne nécessitent pas une reconstruction complète pour devenir opérationnels. Créer des outils d’annotation de données plus accessibles pour que les experts métier voient et jugent ce que fait réellement l’IA avec leurs données. Améliorer la lisibilité du raisonnement des LLM pour l’équipe afin de mieux le valider. Au final, il s’agit de revenir aux fondamentaux du management produit — transformer l’expertise métier en instructions exploitables et réduire ce qui se perd chaque fois qu’une idée quitte la tête du fondateur pour devenir réalisable.

Quand vous allez aussi vite, une équipe désalignée ne reste pas discrètement désalignée. Elle expédie son désalignement.

Avec le recul, tout cela visait surtout à resserrer la boucle de rétroaction, et à rapprocher la personne qui sait réellement si quelque chose est correct, le plus tôt possible du travail. Ce n’est pas une découverte liée à la conception ou à l’IA. C’est en réalité une question organisationnelle. L’IA ne fait que la rendre plus pressante — car à cette vitesse, une équipe désalignée ne reste pas discrètement désalignée. Elle expédie son désalignement.

La version plus difficile et moins discutée de ce problème, c’est qu’on a à peu près résolu le travail en solo avec l’IA. Le travail d’équipe avec l’IA, non. Le contexte partagé se fragmente quand chacun évolue dans sa propre session. Maintenant que l’IA peut générer dix versions de quelque chose, l’équipe doit encore décider laquelle est la bonne — selon quels critères, et qui tranche. Si l’expertise métier réside dans la tête d’une seule personne, tout le système ne va aussi vite que cette personne peut rester dans la boucle.

Nous cherchons certaines de ces réponses avec des équipes pionnières dans ces nouvelles façons de travailler. Ce qui est excitant, c’est de voir comment la conception organisationnelle et la conception agentique peuvent s’influencer, révélant de nouveaux schémas à mesure qu’on avance dans ce domaine émergent. Tandis que la plupart des équipes évoluent actuellement dans le même état, je crois que le véritable travail consiste à apprendre plus de la friction que des cadres théoriques.

Si c’est le genre de problème qui vous intéresse, parlez-nous pour rejoindre Toboggan Labs.