Ingénierie d'intégration axée sur l'IA avec Claude Code : une véritable session de débogage

La plupart des exemples de « code écrit par une IA » sont des démonstrations avec des instructions et des résultats impeccables. Ce n'est pas le cas ici. Il s'agit d'une véritable session sur un véritable produit d'intégration APIANT, incluant les instructions réelles, les erreurs de manipulation, les corrections et le moment où la mémoire humaine a pris le dessus sur la machine.

L'important n'est pas que l'IA soit impressionnante, mais plutôt à quoi ressemble concrètement la collaboration lorsqu'on se met au travail.

La configuration

Ce produit fait partie de nos intégrations CRMConnect. Mindbody vers HubSpotUn client a signalé un problème de synchronisation des ventes réglées par plusieurs moyens de paiement. Une vente de 8 400 $ répartie sur trois modes de paiement apparaissait dans HubSpot comme une seule transaction de 400 $. Les 8 000 $ restants étaient absents du pipeline.

Nous suivons le travail d'ingénierie dans les issues GitHub. Les échanges avec le client sont consignés dans HubSpot Service Hub. La session a débuté lorsque le développeur a orienté l'IA vers le travail en cours.

Rapide: « Examinez la question du paiement »

L'IA a exploré les problèmes GitHub du dépôt, trouvé l'incident ouvert, récupéré l'intégralité du descriptif et l'a relu : un bug de vente à paiements multiples, avec deux identifiants d'exécution en production cités comme preuves. Aucune assistance supplémentaire n'était nécessaire. Elle a ensuite demandé clairement la marche à suivre, sans deviner.

Rapide: « Que fait la logique et quelles sont les automatisations/actions ? »

L'IA a chargé l'automatisation concernée depuis la plateforme, a analysé sa structure étape par étape et a expliqué précisément l'erreur. L'automatisation génère une clé de déduplication pour chaque transaction HubSpot. Pour les ventes à paiements multiples, Mindbody renvoie une ligne par mode de paiement, toutes partageant la même clé. Par conséquent, les lignes deux et trois sont entrées en conflit avec la transaction créée par la ligne un et leurs montants ont été ignorés.

Utile. Mais le constructeur avait déjà une avance plus importante.

L'indice qui a tout changé.

Rapide: « Comparez cet identifiant unique pour l'accord avec la façon dont nous procédons dans le cadre du projet crmconnect-mindbody-zoho. Je pensais que nous avions trouvé une solution. Faites une comparaison très ciblée. »

Cette simple phrase a transformé l'ouvrage. Le concepteur n'a pas décrit de solution. Il a simplement indiqué un produit similaire et a dit, en substance : « Allez le consulter. »

L'IA l'a donc fait. Elle a ouvert le Mindbody vers Zoho L'intégration, un produit totalement distinct, a localisé et lu le processus d'automatisation gérant l'historique des ventes. Ensuite, elle a trouvé et lu la sous-routine enregistrant les paiements, et non des récapitulatifs. Elle a analysé la logique d'automatisation dans son intégralité, étape par étape.

Elle a abouti à une comparaison ciblée. L'intégration de Zoho avait effectivement résolu ce problème, mais avec une architecture différente :

• Le produit HubSpot enregistre une transaction unique par ligne de vente, en utilisant l'ancien point de terminaison de vente de Mindbody, qui renvoie des lignes de paiement pré-divisées.
• Le produit Zoho crée un enregistrement d'achat principal ainsi que des enregistrements enfants distincts pour les articles et pour les paiements, en utilisant le nouveau point de terminaison de Mindbody, où chaque paiement possède son propre identifiant de paiement réel.

L’IA a conclu que Zoho présentait une architecture plus propre et a initialement proposé de transférer l’ensemble du modèle à trois objets dans HubSpot.

Le constructeur réduit la portée.

C'est là que l'humain a permis de garder les choses ancrées dans la réalité.

Rapide: « La version 4.0 n'est pas encore prête. On la verra plus tard ; pour l'instant, il faut corriger les problèmes de transactions manquantes signalés par les clients. »

L'IA s'était orientée vers une refonte architecturale satisfaisante. Le concepteur est revenu à l'essentiel : le client a besoin de montants de transactions corrects, et non d'un nouveau modèle de données. L'IA a acquiescé, a classé la proposition de refonte comme tâche ultérieure et s'est concentrée sur une correction ciblée des automatisations de transactions existantes.

Cette correction est importante. L'IA excelle à trouver la solution générale élégante. En revanche, elle a parfois du mal à discerner quand cette solution élégante dépasse les besoins de la situation. Le concepteur a formulé ce jugement en une phrase.

L'IA a ensuite adapté le principe de conception de Zoho, sans toutefois en copier la structure : rapprocher une transaction par ligne de vente, exploiter les données du point de terminaison plus complet de Mindbody et agréger correctement le montant des différents modes de paiement au lieu de laisser le premier paiement écraser les autres. Plateforme différente, actions différentes, même idée de base.

L'intuition

Lors de la refonte de la clé de déduplication, l'IA a examiné l'un de ses composants : une date. Son raisonnement était limpide. L'identifiant de vente et l'identifiant du détail de vente rendent déjà la clé unique. La date est redondante. Elle a recommandé de la supprimer afin de simplifier la clé et d'éliminer une source de fragilité entre les deux automatisations.

Le constructeur n'avait pas de code source à contester. Il n'avait que sa mémoire.

Rapide: « Il me semble me souvenir que j'ai ajouté la date parce que c'était nécessaire (deux paiements pour la même transaction, ou quelque chose d'aussi bizarre) ? »

Aucun des deux ne pouvait le prouver avec le système automatisé actuel. L'IA a donc consulté l'historique des versions du système. Celui-ci comptait quatre-vingt-treize versions enregistrées, remontant jusqu'à 2021. L'IA a analysé les descriptions des modifications jusqu'à trouver celles qui étaient pertinentes.

À partir de janvier 2022 :

« Ajout de l'identifiant EPOCH MILLIS à la base de données pour garantir l'unicité de l'identifiant de transaction lors de paiements multiples sur un même article. »

À partir de février 2022 :

« Ajout d'une date de vente pour la recherche d'offres par propriété personnalisée afin de traiter les paiements des ventes précédentes »

Voilà, selon les propres termes du constructeur, quatre ans plus tôt. Lorsqu'un client effectue un paiement ultérieur pour une vente antérieure, Mindbody réémet cette vente à la nouvelle date. Sans cette date dans la clé, le paiement ultérieur entre en conflit avec la transaction initiale et ne peut être enregistré séparément. La date n'était pas superflue ; elle était essentielle, ajoutée délibérément pour gérer les paiements échelonnés et les prélèvements automatiques.

L’IA a réagi en revenant immédiatement sur sa recommandation et en l’affirmant clairement :

« Fiez-vous à ce souvenir. Si vous avez ajouté la date intentionnellement, elle est essentielle et il est hors de question de la supprimer. Je l’ai trouvée dans l’historique des versions. »

Le processus s'est ensuite complexifié. La date étant fixe, les deux automatisations devaient impérativement produire la même valeur, sous peine de voir apparaître des doublons. L'automatisation initiale calcule la date à partir d'un champ spécifique de Mindbody. L'IA a ensuite configuré la nouvelle automatisation pour qu'elle lise ce même champ, via le même appel API et avec la même conversion de fuseau horaire. Même entrée, même sortie : les clés sont garanties de correspondre.

Une régression qui aurait discrètement perturbé la gestion des paiements échelonnés ne s'est jamais produite. Non pas grâce à la prudence de l'IA, mais parce qu'un humain s'est souvenu d'une intuition et que l'IA a pu la vérifier en quelques secondes grâce à quatre années d'historique.

La partie ingrate : compiler, exécuter, lire la trace, corriger

Une fois la conception finalisée, on est passé à une ingénierie itérative. On implémentait la modification dans un environnement de développement, on l'exécutait, on analysait la trace d'exécution, on repérait le problème suivant, on le corrigeait, et on relançait. Les vrais bugs étaient ordinaires :

• Une étape de négociation a échoué avec seize personnes. PROPERTY_DOESNT_EXIST Des erreurs se produisaient car les liaisons de champs ne contenaient pas les noms de propriétés internes de HubSpot. L'IA a analysé la trace, récupéré le schéma de champs du connecteur et réattribué chaque champ à son ID correct.
• Une boucle s'est exécutée deux fois au lieu d'une seule, car la plateforme comptabilisait les itérations à partir du tableau le plus long des données sources, et le tableau des paiements était plus long que celui des lignes de commande. L'IA a inséré une commande d'itération explicite afin que la boucle ne compte que les lignes de commande.
• L'étape de recherche d'accord a interrompu l'exécution complète en l'absence d'accord, car son mode d'erreur par défaut considérait « accord introuvable » comme fatal. L'IA a donc opté pour le mode « continuer en cas d'erreur » afin que la création de la branche puisse se dérouler, conformément au comportement déjà observé par l'automatisation précédente.

Rien de tout cela n'est glamour. C'est la réalité du travail d'intégration. Ce qui a changé, c'est la vitesse d'exécution. L'IA pouvait lire une trace d'exécution complète, étape par étape, et identifier immédiatement l'étape défaillante ; chaque cycle de correction ne prenait donc que quelques minutes. Rien n'était livré au client tant que les tests de développement n'étaient pas validés.

Ce que cela signifie pour les constructeurs

Si on enlève tout le récit, voici le modèle opérationnel :

• Le point fort de l'IA est la lecture. Elle a étudié l'intégration complète d'un système frère, a recoupé un problème que nous avions déjà résolu, a adapté une architecture à deux plateformes différentes et a passé au crible quatre-vingt-dix versions de l'historique pour vérifier une seule décision de conception. Aucun humain ne peut accomplir cela en un après-midi.
• La force de l'être humain réside dans sa mémoire et son jugement. « Je pense que j'ai ajouté ça pour une raison » ne figure dans aucun fichier. « Pas encore prêt pour la version 4.0 » ne figure dans aucun fichier. Ces deux affirmations proviennent de mon expérience avec le produit. Chacune a influencé le résultat.
• La vitesse provient de la boucle. Lisez la trace, corrigez l'étape, relancez. Les difficultés qui ralentissent habituellement le débogage et la reconstitution des événements disparaissent.

L'ingénierie d'intégration axée sur l'IA ne consiste pas à faire travailler l'IA seule, ni à faire travailler l'humain plus vite. Il s'agit plutôt de l'IA qui effectue les recherches qu'aucun humain n'a le temps de faire, et de l'humain qui fournit le contexte absent du code source. Grâce à cette combinaison, un bug récurrent vieux de quatre ans est compris, corrigé et vérifié en une seule session de travail.

Voilà le flux de travail qu'il vaut la peine de développer.