01 Contexte & Problème
Le client proposait un produit BNPL axé sur le bail : les clients demandaient une limite de dépenses approuvée, puis finançaient des achats éligibles et remboursaient selon un calendrier de paiement éclectique au lieu de payer la totalité. Le produit ne couvrait que les objets louables tels que les meubles, les téléviseurs et l’électronique grand public, pas les consommables de faible valeur comme les stylos, carnets et papeterie. Le client a grandi en intégrant son option de paiement directement sur le site web de chaque détaillant : les ventes s’approchent du détaillant, le détaillant fournit un bac à sable, l’équipe intègre la passerelle, l’ingénierie et le contrôle qualité testent le paiement, puis les deux parties coordonnent une version de production.
Ce modèle fonctionnait chez cinq à sept détaillants et s’est effondré à mesure que le réseau grandissait. Les détaillants utilisaient différentes combinaisons de Shopify, Magento, BigCommerce et des plateformes personnalisées, différents paiements, différents processeurs de paiement, ainsi que des procédures de sandbox et de libération, de sorte que chaque intégration devenait son propre cycle de vie permanent et de support. Toute mise à niveau de plateforme ou changement de paiement du distributeur pourrait obliger le client à reconstruire l’intégration, refaire les tests de régression et programmer une nouvelle sortie conjointe. Après environ six mois, le programme soutenait environ 15 détaillants avec 60 à 70 personnes, et le plan était de 200+ détaillants l’année suivante : une extension linéaire impliquait des centaines, potentiellement près d’un millier, de personnes. Le vrai problème n’était pas la capacité de développement. L’architecture a fait de chaque nouveau détaillant une nouvelle dépendance externe, donc le client avait besoin d’un modèle où la croissance des détaillants ne nécessitait plus une croissance proportionnelle en ingénierie et en support.
02 Rôle et contraintes
En AI Product Manager , je possédais la solution de bout en bout : stratégie produit, définition du problème, conception du parcours client, définition de cas d’usage IA, architecture de solution, stratégie d’activation des détaillants, exigences en données produit et étiquetage, coordination ingénierie et IA/ML, exigences API et backend, intégration des cartes virtuelles, expériences mobiles et extensions de navigateur, coordination sécurité et conformité, exigences analytiques et de performance des modèles, planification du déploiement et gestion des parties prenantes. L’un des appels les plus importants a été de définir où l’IA devait ou ne devait pas être utilisée : le modèle ne répondait qu’à savoir si un produit était éligible selon la politique de produit louable. Il n’a pas déterminé la solvabilité, fixé de limites de crédit, validé l’identité, défini les conditions de remboursement, effectué la vérification du SSN ni approuvé les comptes, tout cela restant fidèle aux systèmes d’approbation, d’identité et d’accord existants du client.
Les contraintes étaient concrètes. Éliminez la dépendance à l’implémentation côté distributeur : aucun détaillant ne devrait avoir à ajouter un mode de paiement, fournir un accès bac à sable, modifier son paiement, exposer des API personnalisées, assigner des développeurs ou exécuter une assurance qualité conjointe. Soutenir l’éligibilité au niveau du produit, puisqu’un détaillant pouvait vendre à la fois des articles louables et non louables, le système classait donc les articles individuels du panier plutôt que les détaillants entiers, et gérait les paniers mixtes en finançant uniquement la partie éligible. Travailler avec différentes technologies de détaillants et gérer les modifications du DOM, car l’extension continue de lire les pages des détaillants et les mises à jour de pages pourraient modifier la structure HTML, les sélecteurs, les cartes produits, les prix et les champs de paiement. Maintenir une précision de classification acceptable, généralement entre 85 et 90 % avec une cible supérieure à 90 et une amélioration vers 95. Protègez les informations clients (nom, adresse, numéro de portable, SSN et OTP) par le chiffrement, la tokenisation, les contrôles d’accès et la consigne d’audit. Et plus tard, soutenir le commerce physique sans intégrer le système de point de vente de chaque magasin.
03 Approche produit
Au lieu de constituer une équipe d’intégration plus efficace pour les détaillants, nous avons changé l’emplacement de l’intégration. Le modèle original plaçait la capacité de financement du client à la caisse du distributeur. Le modèle repensé plaçait l’expérience de financement dans les canaux contrôlés par le client : une extension Chrome pour le commerce électronique et l’application mobile du client pour les magasins physiques. Cela a créé une plateforme partagée, indépendante des commerçants, qui fonctionnait dans de nombreux détaillants sans qu’aucun détaillant n’implémente la méthode de paiement du client.
En ligne, la Chrome extension identifiait le détaillant, informait le client de la possibilité d’un financement, lisait le panier et le total, envoyait les détails du produit à l’arrière-plan, classait chaque article comme louable ou non, excluait les articles non éligibles, vérifiait le montant éligible par rapport à la limite du client, soutenait l’enregistrement et la vérification, présentait l’accord, générait une carte virtuelle à usage unique ou à usage limité, et l’a rempli automatiquement dans la caisse standard du détaillant. Permettre à un nouveau détaillant est devenu un processus géré en interne plutôt qu’une intégration bilatérale de six mois : collecter les données publiques du catalogue du détaillant, étiqueter les produits louables ou non louables selon la politique du client, former ou mettre à jour le classificateur sur des milliers d’enregistrements, valider la précision par rapport aux labels connus, configurer l’extraction DOM pour le nom du produit, le prix, la quantité, la catégorie et le total du panier, Testez le flux de bout en bout, puis activez le détaillant, sans besoin de sandbox, de changement de paiement ou de déploiement de passerelle.
En magasin, nous avons étendu la même capacité à l’application mobile. L’application détectait que le client se trouvait à l’intérieur de la géorepérage d’un magasin ; au comptoir de facturation, le client photographiait la facture détaillée ; OCR extrait les noms, quantités et prix des produits ; les lignes ont été normalisées et transférées au même modèle d’éligibilité ; l’application séparait les articles éligibles des non éligibles afin que les produits non louables puissent être payés séparément ; le total éligible a été vérifié par rapport à la limite ; Le client a accepté l’accord ; Une carte virtuelle a été générée pour le montant éligible et utilisée selon le processus d’acceptation de carte habituel du magasin. Si le client quittait la géorepérage avant d’utiliser la carte, elle expirait automatiquement. Le géorepérage n’a pas traité la transaction, il a agi comme un déclencheur pour que le backend modifie le statut du cycle de vie de la carte.
Le client semblait avoir besoin d’une équipe d’intégration plus importante. Le vrai problème était que la croissance dépendait de centaines de systèmes de distributeurs externes et de calendriers de sortie. Déplacer l’expérience dans une extension contrôlée par le client et une application mobile, avec des cartes virtuelles comme couche d’interopérabilité, a modifié cette dépendance : les données produit du détaillant ont remplacé l’intégration des paiements personnalisés, et chaque article a été décidé indépendamment.
04 Caractéristiques construites
Détection par distributeur supporté
L’extension reconnaît les sites de détaillants activés et informe le financement disponible au client.
Extraction par chariot à base de DOM
La logique DOM spécifique au détaillant extrait les informations produits et paniers de la page.
Éligibilité aux produits IA
Chaque article du panier est classé louable ou non louable par le modèle partagé.
Manutention mixte
Les éléments non éligibles sont exclus, donc seule la partie éligible est financée.
Enregistrement en extension
Les nouveaux clients créent un compte sans quitter le parcours d’achat.
Carte virtuelle + remplissage automatique de la carte
Une carte à usage unique ou à usage limité est générée et remplie automatiquement à la caisse du détaillant.
Voyage mobile en magasin
L’application cliente existante a été étendue pour financer les achats éligibles en magasin physique.
Géorepérage de magasin
L’application détecte lorsqu’un client se trouve dans la zone configurée par un magasin supporté.
Capture de billet + OCR
Le client photographie la facture détaillée ; OCR extrait des éléments de ligne de l’image.
Normalisation des réceptions
OCR production est convertie en relevés structurés de produits, de quantités et de prix.
Répartition éligible / non éligible
L’application affiche ce qui peut être financé et ce qui doit être facturé ou payé séparément.
Expiration déclenchée par géorepérage
Quitter la limite du magasin avant d’être utilisé déclenche automatiquement l’expiration de la carte.
Également expédiés : validation de la limite approuvée, vérification mobile OTP, validation en temps réel du SSN par rapport aux systèmes d’identité existants du client, présentation et acceptation d’accords (dans l’extension et dans l’application), activation répétable du détaillant via formation produit plus configuration DOM, classification partagée des produits réutilisée sur les deux canaux, et un backend omnicanal unique pour l’éligibilité, la validation client, les accords, les cartes virtuelles et les analyses.
Architecture 05
Deux canaux clients convergeaient sur un backend. Le canal en ligne est l’extension Chrome plus l’extraction du DOM par le détaillant ; Le canal en magasin est l’application mobile ainsi que la photographie de factures, la OCR et la géorepérage. Les deux utilisent les mêmes services de base pour la normalisation des produits, la classification des produits louables, l’identité client et la validation des limites de crédit, la génération d’accords, l’émission de cartes virtuelles, la gestion du cycle de vie des cartes, ainsi que l’analyse et la journalisation des audits. Un backend Python expose REST API ; un fournisseur externe de cartes PCI conformes DSS émet les cartes virtuelles à usage unique ou à usage limité.
L’architecture a modifié l’unité d’expansion. Alors que chaque détaillant nécessitait auparavant un accord commercial, des ressources techniques du détaillant, un accès bac à sable, l’intégration des paiements, un contrôle qualité conjoint, une sortie coordonnée et un support continu de la plateforme, un nouveau détaillant en ligne nécessite désormais principalement la préparation des données produit, l’étiquetage, l’entraînement ou la validation du modèle, la configuration du DOM, les tests de paiement et l’activation des extensions. Un nouveau détaillant physique nécessite principalement la configuration de l’emplacement du magasin, la couverture des données produit, la validation du format des reçus, les tests OCR , les tests d’éligibilité et la validation de l’acceptation de la carte. La sécurité couvre le chiffrement, la tokenisation, l’accès restreint, la journalisation des audits, la vérification OTP, la validation en temps réel du SSN, l’exécution contrôlée des accords, les cartes à usage unique ou à usage limité, l’expiration déclenchée par localisation et le fournisseur conforme au PCI DSS. La fiabilité est surveillée par surface : casse du DOM en ligne (produits manquants, sélecteurs invalides, défaillances de remplissage automatique), OCR variabilité en magasin (mauvais éclairage, flou, plis, abréviations, lignes fiscales et de remises), limites de géorepérage (permissions refusées, précision intérieure, dérive GPS, événements de sortie retardés, limites en arrière-plan du système d’exploitation), et résultats de cartes virtuelles (échecs d’émission, délais de diffusion fournisseurs, activation, expiration, autorisation). Les compromis sont explicites : l’indépendance du détaillant dépend toujours du DOM du détaillant ; L’indépendance du POS dépend de la qualité des reçus ; un modèle partagé englobe deux types d’entrée très différents ; le contrôle de localisation est limité par la précision de la localisation ; et le fournisseur externe de carte réduit la charge d’infrastructure tout en augmentant la dépendance au fournisseur.
06 Analytique & Observabilité
La plateforme élargie nécessitait une mesure distincte pour le paiement en ligne, la performance de OCR , la précision du modèle, le comportement de localisation et les résultats de paiement, car une seule défaillance pouvait en provenir de l’un ou d’eux. OCR précision et précision de classification étaient mesurées séparément : une erreur de classification pouvait résulter d’un texte de OCR incorrect, d’un traitement syntaxique incorrect des reçus, d’un contexte produit insuffisant ou d’une véritable erreur de modèle. Un entonnoir e-commerce (le détaillant détecté → prolongation ouverte → panier extrait → classé → montant éligible → vérifié →accord → remplissage automatique → de la carte → achat) et un entonnoir en magasin (le magasin détecté → géorepérage entré → facture photographiée → OCR → lignes → classifiées → non louables, séparées → approuvées →accord approuvé → paiement ou expiration de →la carte) étaient instrumentées de bout en bout. Le profil support a également évolué : loin des intégrations de détaillants, des bacs à sable et des défauts de passerelle, vers la facturation, les accords, le remboursement, la lecture de OCR ou de factures, les modifications du DOM, les questions d’autorisation de localisation et d’autorisation de carte.
Indicateurs des détaillants en ligne
Détection du détaillant, extraction du panier, erreurs DOM, réussite du remplissage automatique et du paiement, conversion d’approbation-achat.
Indicateurs de classification
Précision par détaillant, catégorie et canal, taux faux louables et non louables, et répartition de confiance.
OCR Indicateurs
Capture et traitement du succès, extraction de lignes et de prix, rapprochement total, recapture et taux de correction manuelle.
Métriques de géorepérage
Détection d’entrée, refus d’autorisation, événements de sortie, cartes expirées après sortie, et délai entre la génération et le paiement.
Métriques de cartes virtuelles
Succès de la demande, latence de génération, erreurs de fournisseurs, activation, résultats d’autorisation et taux de carte non utilisée.
07 Couche de décision IA
Le modèle répondait à une question étroitement définie, cohérente sur les deux canaux : ce produit est-il éligible selon la politique de produit louable du client ? Les entrées en ligne combinaient le nom du produit, l’image, la catégorie, le contexte du détaillant, la description lorsque disponible, le prix et la quantité, ainsi que l’étiquette de formation louable/non louable. Les entrées en magasin étaient des descriptions extraites OCR, du texte des articles de reçu, de la quantité, du prix, du contexte du magasin et des données de produits antérieurs des détaillants, qui étaient souvent bien moins descriptifs qu’une page e-commerce, de sorte que la normalisation des produits était la plus importante dans le flux en magasin. Le pipeline recueillait les informations produits du DOM ou du reçu, normalisait le texte spécifique au détaillant, les mappait dans des catégories connues, évaluait la location, renvoyait le résultat, calculait le total éligible et enregistrait le résultat et la version du modèle pour surveillance. La formation utilisait des données structurées sous forme de tableur (nom, image, catégorie, détaillant, étiquette) avec des milliers d’exemples par détaillant ou groupe de détaillants, un modèle supervisé de classification de produits. La précision rapportée était d’environ 85 à 90 %, avec un objectif de dépasser 90 et d’atteindre 95 ; il s’agissait de la mesure au niveau du projet du client, sans précision distincte, rappel, F1 ou évaluation auditée indépendante.
L’IA n’a répondu qu’à l’éligibilité au produit. Il n’a jamais déterminé la solvabilité, fixé de limites de crédit, validé l’identité, défini les conditions de remboursement, effectué la vérification du SSN ni approuvé les comptes, ces derniers restaient avec les systèmes existants du client. Les modes de défaillance connus (un article non louable noté louable, un article louable mal refusé, une ligne de réception abrégée mal cartographiée, un produit regroupé ou tout neuf, une taxonomie du détaillant modifiée ou un mauvais OCR) indiquent l’étape suivante recommandée : la décision basée sur la confiance qui continue automatiquement lorsqu’elle est confiante, applique des règles de catégorie déterministes à confiance moyenne, demande au client de recapturer à faible confiance, et exclut ou envoie à réviser en cas de résolution non résolue.
08 Statut et Résultats
L’extension Chrome a soutenu 100+ détaillants en environ quatre mois, contre environ six mois pour 15 sous le modèle initial, et a finalement permis aux clients d’utiliser le produit de financement auprès de 300+ détaillants en ligne, soit une augmentation d’environ vingt fois par rapport au seuil de 15 détaillants. Un nouveau détaillant n’avait plus besoin de ressources techniques, d’accès bac à sable, d’intégration de passerelle, de QA conjoint, de déploiement côté distributeur ou de lancements coordonnés ; il pouvait être rendu possible grâce à la préparation des données, l’étiquetage, l’entraînement du modèle, la configuration du DOM, les tests de vérification et l’activation des données contrôlées en interne. L’équipe initiale de 60 à 70 personnes est restée globalement la même, avec environ quatre à cinq ingénieurs IA/ML ajoutés pour la préparation des données, l’entraînement des modèles et la précision, évitant ainsi l’augmentation proportionnelle du personnel suggérée par l’ancien modèle. Les travaux d’intégration par les détaillants, le développement personnalisé, l’effort bac à sable, les tests conjoints et la maintenance des paiements spécifiques à la plateforme ont été supprimés ; Le client a rapporté une augmentation du volume des transactions de paiement à mesure que de plus en plus d’établissements acceptaient la limite approuvée (rapportée qualitativement, sans chiffre exact fourni). La plateforme s’est ensuite étendue au commerce de détail physique via l’application mobile, prouvant que le modèle de base ne se limitait pas au paiement web, et que les coûts liés à des intégrations répétées, des bacs à sable, du développement de passerelles, de l’assurance qualité conjointe, de la coordination des versions et de la croissance proportionnelle du support se sont améliorés, le fournisseur de cartes virtuelles étant la principale dépendance externe restante.
300+
Les détaillants en ligne soutenus
20×
Augmentation de la couverture des détaillants
4 mo
À 100+ détaillants (contre 6 mois pour 15)
85-90%
Précision rapportée du modèle
09 Réflexion / Et après
Ce qui a fonctionné, c’est de résoudre le problème de dépendance plutôt que celui du personnel : une capacité d’éligibilité servait les pages web, les paniers et les factures extraites OCR, les cartes virtuelles permettaient au client d’opérer via des flux de paiement déjà pris en charge par les détaillants, et chaque canal ajoutait ses propres contrôles (extraction DOM et remplissage automatique en ligne ; OCR, géorepérage et expiration de carte en magasin) sur une plateforme partagée cohérente. Ce que j’améliorerais ensuite : formaliser l’activation des détaillants comme un produit d’opérations internes (téléchargement, étiquetage, formation, validation, configuration du DOM et du magasin, approbation des sorties, surveillance de la santé) ; ajouter la conciliation des reçus afin que les totaux extraits, les remises et les impôts se concilient avec la facture finale ; introduire une politique d’examen de faible confiance ; renforcer les contrôles géorepérateurs avec des échéances courtes, des limites de montant et de transaction unique, ainsi qu’une fermeture immédiate après autorisation ; construire une détection automatisée de changement de DOM via des tests synthétiques programmés ; un rapport séparé de OCR et d’erreurs d’IA sur les tableaux de bord ; améliorer la traçabilité de la gouvernance du modèle (canal, détaillant, modèle et version des données d’entraînement, entrées, confiance en OCR et classification, version de l’accord, résultat de la carte) ; et s’étendre prudemment à Android et iOS compte tenu de leurs différentes autorisations et comportements de localisation en arrière-plan. Le résultat durable a été une plateforme omnicanale où les données produits des détaillants ont remplacé l’intégration des paiements personnalisés, l’IA déterminait l’éligibilité, les systèmes existants géraient l’identité et le crédit, les cartes virtuelles créaient l’interopérabilité, et le navigateur et le mobile donnaient au client le contrôle de la distribution, dissociant la croissance de l’entreprise de l’effort d’ingénierie.