La plupart des articles techniques sur l’ajout de l’IA à un produit commencent par l’IA. Celui-ci commence par l’endroit où nous avons choisi de ne pas l’utiliser.
Un partenaire est venu nous voir avec un problème classique : un processus critique pour son activité, qui reposait encore presque entièrement sur des tableurs. Les données arrivaient chaque jour d’un large réseau de partenaires externes, chacun avec son propre format, sans structure commune ni visibilité partagée sur l’avancement de chaque dossier. Le vrai goulot d’étranglement n’était pas le travail lui-même, mais sa coordination manuelle.
C’est exactement le type de problème autour duquel notre équipe solutions IT dédiées construit du logiciel sur mesure : remplacer le processus manuel par une plateforme qui importe les données entrantes, les dirige vers les bons spécialistes internes, suit le statut de bout en bout, et donne à tous une vue unique et à jour de la situation.
La stack a été imposée par le partenaire, et c’était très bien ainsi. Angular en frontend, NestJS en backend, Microsoft SQL Server comme base de données, le tout aligné avec ce que la petite équipe technique interne du partenaire connaissait déjà et allait devoir maintenir. Nos développeurs auraient fait d’autres choix par défaut. Peu importe. L’équipe qui reprend la main après nous a son mot à dire sur la stack, c’est un arbitrage simple : notre préférence à court terme contre leur responsabilité de maintenance à long terme.
Le problème intéressant n’était pas technique, il était structurel. Chaque partenaire externe exportait ses données différemment. Noms de colonnes différents, structures différentes, conventions différentes pour la même information sous-jacente. Avant qu’un spécialiste interne puisse traiter un dossier, quelqu’un devait retravailler manuellement le fichier pour le rendre cohérent. Cette étape de reformatage était surtout une surcharge opérationnelle : elle ne mobilisait pas le jugement métier pour lequel les spécialistes étaient nécessaires, mais restait un travail fastidieux et source d’erreurs entre l’arrivée des données et le vrai travail.
C’est le seul endroit où nous avons utilisé l’IA. Elle intervient à l’import et mappe les fichiers entrants vers une structure interne cohérente, même lorsque les tableurs sources utilisent des structures, noms de colonnes ou conventions différents. Les correspondances ambiguës sont signalées pour vérification humaine plutôt qu’acceptées automatiquement. Le périmètre de l’IA est volontairement restreint : normalisation de format, pas prise de décision. Elle ne prend ni ne valide les décisions de fond qui suivent. Celles-ci restent entre les mains des spécialistes du partenaire. Dans un processus où une mauvaise décision peut avoir une conséquence financière ou réglementaire directe, l’IA est utile pour préparer des données structurées, pas pour remplacer le jugement humain responsable. C’est une frontière sur laquelle notre équipe AI Development revient sur presque chaque projet réglementé ou à forts enjeux.
Le reste de la plateforme, c’est ce qu’on attend d’un bon outil interne : une file d’attente pour répartir le travail, un suivi de statut fiable, et une messagerie intégrée rattachée à chaque dossier, pour que les questions ne se perdent pas dans des fils d’e-mails.
Travailler avec une équipe réduite côté partenaire change la façon de livrer. Il n’y avait pas de place pour attendre des spécifications détaillées entre deux points d’étape, alors nous ne les avons pas demandées. Le partenaire nous a donné un brief général et de haut niveau, avec des cycles de démo réguliers, et notre équipe dédiée a pris directement les décisions d’UX et de logique métier, validées en direct à chaque démo. Ce modèle ne fonctionne qu’avec un partenaire qui fait confiance à l’équipe pour prendre rapidement des décisions produit pragmatiques, tout en conservant une trace légère des décisions clés, des retours de démo et des points d’acceptation. Il nous a permis d’avancer plus vite qu’un processus plus lourd de spécification puis validation, sans perdre la traçabilité nécessaire à la reprise en maintenance.
Le résultat est un processus qui tournait autrefois sur des tableurs dispersés et qui fonctionne désormais sur une plateforme avec une vue opérationnelle unique et claire.