Trouver les articulations : comment PAR Technology repense le développement assisté par l'IA

Harrison Wright est architecte et responsable de la stratégie des plateformes d'IA chez PAR Technology, où il dirige la stratégie d'IA d'entreprise et le développement de la plateforme pour trois unités commerciales. Il possède plus de huit ans d'expérience dans le déploiement de logiciels en production, et a notamment fondé et revendu une entreprise technologique.

____________________________________________________________________________

Le Zhuangzi raconte l'histoire d'un boucher nommé Cuisinier Ding. Son couteau ne s'émousse jamais, non pas parce qu'il était plus tranchant que celui des autres, mais parce qu'il ne coupait jamais les os. Il repérait les articulations naturelles de chaque morceau de viande et y glissait la lame sans la moindre résistance.  

Nous pensons que c'est la bonne métaphore pour le développement logiciel assisté par l'IA — et c'est le principe qui sous-tend le flux de travail de développement agentique que nous avons mis en place et déployé chez PAR Technology.  

Le problème de l'utilisation de l'IA par la plupart des équipes 

La plupart des équipes d'ingénierie utilisent les assistants IA de deux manières : comme moteur de saisie automatique ou comme interlocuteur. Soit ils reçoivent des suggestions de code intégrées ligne par ligne, soit ils ouvrent une fenêtre de discussion et tentent de décrire une fonctionnalité complète en une seule conversation.  

Ces deux approches présentent le même problème fondamental : elles considèrent le développement logiciel comme une activité unique et continue, comme si comprendre ce qu’il faut construire, décider comment le construire et le construire réellement relevaient du même raisonnement. 

Ils ne sont pas. 

Comprendre un problème est un processus divergent, exploratoire et semé d'embûches. Choisir une approche architecturale est comparatif, analytique et exige de concilier plusieurs options. Écrire du code est séquentiel, convergent et requiert de la précision. Demander à une IA de faire ces trois choses à la fois, c'est comme lui demander de trancher un os.  

Trois espaces, trois types de pensée  

Notre approche repose sur l'idée que chaque tâche de développement traverse trois modes cognitifs distincts : l'espace du problème, l'espace de la solution et l'espace de l'implémentation.  

L'espace problème consiste à découvrir la véritable nature du problème. Qu'est-ce qui ne fonctionne pas ? Pourquoi ? Quelles contraintes existent sans être évidentes ? Quels besoins concurrents créent des tensions ? Le travail est ici socratique : poser les bonnes questions jusqu'à ce que le problème soit suffisamment circonscrit pour être résolu.  

L'espace des solutions consiste à explorer comment résoudre un problème bien défini. Il ne s'agit pas de se précipiter sur la première réponse, mais de générer des approches véritablement différentes, de les évaluer au regard des contraintes réelles et d'en choisir une en toute connaissance de cause, en sachant ce que cela implique comme compromis.  

L'espace d'implémentation consiste à concrétiser l'approche choisie : décomposer une architecture en étapes exécutables, les construire dans le bon ordre et vérifier le résultat par rapport à l'intention initiale.  

Il ne s'agit pas de phases dans un plan de projet. Ce sont des types de travail cognitif fondamentalement différents. C'est leur mélange qui pose problème au développement assisté par l'IA : résoudre des problèmes que l'on n'a pas pleinement compris, coder avant d'avoir adopté une approche, ou encore remettre en question des décisions architecturales en cours d'implémentation.  

La séparation est le système. 

Ce que nous avons construit  

Nous avons développé un flux de travail structuré, basé sur l'intelligence artificielle, qui attribue aux agents des rôles spécialisés adaptés à chaque mode cognitif. Plutôt qu'une conversation unique entre agents qui tenterait de tout gérer, notre pipeline répartit les tâches en phases distinctes, chacune avec ses propres comportements, entrées et sorties, et des règles claires définissant ses actions et ses exclusions.  

Dans l'espace problème, l'IA agit comme un partenaire d'exploration : elle pose des questions de clarification, fait émerger les tensions entre les besoins concurrents et détermine quand le problème a été suffisamment exploré pour aller de l'avant.  

Dans l'espace des solutions, l'IA passe à l'exploration architecturale : génération de multiples approches, évaluation des compromis par rapport aux contraintes spécifiques du problème et aide à l'ingénieur pour parvenir à une décision de conception, sans faire le choix à sa place.  

Dans l'espace d'implémentation, l'IA devient un exécutant : elle suit un plan structuré, vérifie son travail par rapport aux spécifications et signale tout problème plutôt que d'improviser une solution de contournement.  

Chaque phase produit un document — un cahier des charges, un cahier des charges architectural, un plan de mise en œuvre — qui sert de référence pour la phase suivante. Ces documents constituent les contrats entre les phases. Ils préviennent les dérives, garantissent une transition fluide du contexte et offrent à chaque phase un point de référence clair sur les décisions prises en amont.  

Pourquoi les limites importent plus que les agents  

L'élément le plus précieux de ce système ne réside pas dans le comportement de l'IA au cours d'une phase donnée, mais dans les frontières entre les phases.  

Lorsque la phase d'implémentation constate que l'architecture ne se décompose pas facilement, elle n'improvise pas : elle renvoie le travail à l'espace des solutions en fournissant une constatation précise. Si l'exploration de l'espace des solutions révèle que le problème initial comportait une contrainte critique manquante, elle marque une pause et revient à l'espace du problème plutôt que de contourner cette lacune.  

Ce flux inverse confère au système son caractère autocorrecteur. Chaque phase en aval sert de couche de validation à la précédente. Les erreurs sont détectées à temps, lorsqu'il est encore facile de les corriger, avant qu'elles ne soient enfouies sous des couches d'implémentation.  

Cela permet également d'éviter le mode d'échec le plus fréquent observé dans le développement assisté par IA : la remise en question de l'architecture lors de l'implémentation. Une fois la décision prise et documentée dans la chaîne d'artefacts, la phase de compilation s'y fie. Si une étape d'implémentation s'avère plus complexe que prévu, le système réagit par défaut en la poursuivant, car cette difficulté était probablement un coût anticipé d'un compromis déjà évalué. La spécification avait déjà répondu à la question « ne serait-il pas préférable de… » lors de la phase appropriée.  

Où cela se fait  

Le processus a fait l'objet de deux refontes majeures, basées sur son utilisation réelle par notre équipe d'ingénierie. Il permet de mener à bien des projets de développement basés sur l'IA à une vitesse qui a transformé notre vision des possibilités offertes par un cycle de sprint.  

Plus important encore, il s'attaque aux problèmes les plus complexes. Non seulement aux projets entièrement nouveaux, mais aussi aux vastes bases de code établies, fruit de plusieurs années de contributions multiples. Le genre de code avec lequel la plupart des outils d'IA peinent, faute de style d'auteur unique, d'architecture claire à suivre et d'une multitude de conventions implicites non documentées.  

C’est la phase structurée de délimitation du problème qui rend cela possible. Avant même que l’IA n’écrive une seule ligne de code, elle dispose d’un problème délimité, d’une approche choisie avec des compromis documentés et d’un plan qui tient compte des modèles et conventions spécifiques du code source. Cette réflexion en amont est suffisante avant le début de l’exécution.  

Et après  

Nous sommes en train de transposer ce flux de travail, initialement conçu comme un outil de développement en ligne de commande, en un système multi-agents déployé à l'aide de LangGraph. L'objectif est de dépasser la simple productivité individuelle des développeurs pour parvenir à une orchestration à l'échelle de l'équipe : le pipeline structuré devient ainsi une infrastructure accessible à tous les ingénieurs, et non plus seulement à ceux qui maîtrisent parfaitement le flux de travail.  

Nous explorons également comment la phase d'analyse du problème peut servir des rôles allant au-delà de l'ingénierie. La même exploration structurée qui aide un ingénieur à cerner un problème technique peut aider un chef de produit à définir une demande de fonctionnalité ou un décideur métier à exprimer un besoin. Le document de synthèse issu de cette phase ne requiert pas d'expertise technique ; il exige une réflexion rigoureuse, ce que favorise précisément le comportement de l'agent.  

Le développement assisté par l'IA n'en est qu'à ses débuts. La plupart des équipes découvrent les solutions efficaces par tâtonnement. Nous sommes convaincus que la réponse ne réside pas dans de meilleurs modèles ou des fenêtres de contexte plus larges, mais dans une meilleure structuration de l'utilisation des modèles existants.  

Repérez les articulations naturelles. Guidez la lame. Laissez l'IA faire ce qu'elle sait faire de mieux, dans le bon ordre et avec les contraintes appropriées.   

Le couteau de Cook Ding ne s'est jamais émoussé. Nous pensons qu'il y a une leçon à en tirer.