Notes du studio — les bonnes données avant l’agent
Cette semaine, la flotte d’agents a retravaillé, chez un courtier en assurance, un agent d’analyse de polices pour qu’il ne conserve plus aucun fichier, et chez une agence de voyages, transformé une décennie de tableurs éparpillés en un catalogue unique et structuré. Deux chantiers, une même leçon : savoir précisément quelles données votre IA manipule, et ne lui donner que le strict nécessaire, le plus propre possible.
Chaque semaine, la même flotte d’agents intervient chez plusieurs clients à la fois. Cette semaine, deux chantiers distincts partagent le même fil : chez un courtier en assurance, le studio a reconstruit un agent d’analyse pour qu’il cesse de conserver les documents qu’il lit ; chez une agence de voyages, il a transformé des années de tableurs éparpillés en un catalogue structuré unique. Deux mouvements opposés — ne rien garder d’un côté, tout organiser de l’autre — mais la même discipline en dessous : savoir précisément quelles données votre IA manipule avant de lui en confier davantage.
Un agent d’analyse de polices qui ne garde aucun fichier
L’agent qui compare les polices existantes d’un courtier en assurance aux besoins réels d’un client lit les contrats PDF envoyés, extrait chaque clause dans une structure fixe — catégorie d’écart, gravité, recommandation, clause source — et restitue le rapport. Le studio a reconstruit ce pipeline en point d’entrée sans état : pas de base de données, pas de système de compte qui conserverait les contrats déposés « au cas où », un fichier lu une fois puis abandonné dès l’analyse restituée. Un rapport de 2009 d’Ann Cavoukian, très souvent cité, Privacy by Design: The 7 Foundational Principles, formule exactement ce choix : une protection de la vie privée assurée par défaut, intégrée à l’architecture elle-même, vaut mieux qu’une politique promettant de supprimer les données plus tard. Leçon pour un courtier ou tout conseiller qui manipule des contrats clients : moins vos systèmes conservent de documents sensibles, plus votre surface de conformité et de risque en cas de fuite se réduit — la minimisation des données n’est pas une ligne de politique interne, c’est une décision d’architecture.
Un catalogue reconstruit à partir d’une décennie de tableurs
Chez l’agence de voyages, la véritable connaissance produit — activités, hébergements, véhicules, tarifs — vivait dans des années de fichiers Excel sans structure commune entre eux, pas dans une base de données qu’un pipeline de réservation pouvait interroger. Avant qu’une recommandation pilotée par IA puisse se brancher sur le système de réservation, le studio a écrit des scripts d’extraction pour normaliser ces tableurs en un catalogue cohérent unique, validé d’abord sur un large jeu de données synthétique avant de toucher à la production. La synthèse souvent citée d’Erhard Rahm et Hong Hai Do, Data Cleaning: Problems and Current Approaches, documente précisément pourquoi cette étape ne peut pas être sautée : des données sources incohérentes, dupliquées ou mal structurées sont la cause d’échec la plus courante de tout système construit par-dessus. Leçon pour un DSI : une grande partie du travail « prêt pour l’IA » dans une entreprise déjà installée n’est pas un choix de modèle — c’est l’excavation et la normalisation des données historiques que l’agent devra réellement exploiter.
Le fil qui relie les deux chantiers de la semaine : un agent ne vaut que par la discipline de données derrière lui — parfois cela veut dire en stocker le moins possible, parfois cela veut dire enfin structurer ce qui s’est accumulé pendant des années. Avant d’ajouter la moindre couche d’IA, le studio pose toujours la même question en premier : de quoi cet agent a-t-il réellement besoin, et pour combien de temps ?
Ressource gratuite
La grille d’auto-diagnostic : 20 tâches automatisables par l’IA
Commercial, administratif, support, opérations : les 20 tâches que des agents IA prennent déjà en charge en PME — avec, pour chacune, le signal qui montre que vos équipes sont concernées.