L'IA pour gérer des inventaires : de GPT-4o à Claude, inventaires photo et cartes grises
Une application d'inventaire utilise l'IA pour éviter la saisie manuelle. Une photo d'une pièce devient une liste d'objets avec marque, modèle, quantité et prix ; une carte grise scannée remplit la fiche du véhicule. Nous avons commencé avec GPT-4o d'OpenAI, puis sommes passés à Claude Haiku 4.5 d'Anthropic pour l'analyse photo : un seul appel au lieu de deux, et une qualité qui vient surtout de consignes affinées erreur après erreur. Dans tous les cas, l'IA propose et l'utilisateur valide.
Utiliser l’IA pour réduire la saisie
Une appliucation développée chez socraft sert à faire l’inventaire d’un patrimoine : immobilier, mobilier, véhicules. Le problème principal, c’est la saisie. Personne n’a envie de rentrer cinquante objets un par un, ni de recopier les quarante champs d’une carte grise.
On a donc ajouté de l’IA à deux endroits. D’un côté, l’analyse de photo : on prend une photo d’une pièce et l'application propose une liste d’objets, avec la marque, le modèle, la quantité et un prix. De l’autre, la lecture de carte grise : on scanne le permis de circulation et la fiche du véhicule se remplit automatiquement.
Dans les deux cas, l’IA ne décide rien toute seule. Elle propose, l’utilisateur relit, corrige si besoin, puis valide. Rien n’est enregistré sans cette étape.
La première version, avec GPT-4o
Au départ, on utilisait GPT-4o d’OpenAI.
Pour les photos, l’image était analysée en haute résolution, avec la recherche web activée pour essayer de trouver un prix neuf réaliste chez des revendeurs suisses : Galaxus, Brack, Jumbo, Hornbach, etc.
Pour les cartes grises, GPT-4o ne lisait pas directement l’image. Google Document AI faisait d’abord l’OCR, puis GPT-4o rangeait le texte brut dans les bons champs.
Ça marchait, mais ce n’était pas idéal. Il fallait d’abord envoyer l’image chez OpenAI, puis lancer l’analyse : deux appels au lieu d’un. Et il y avait un détail pénible : les extensions en majuscules, comme .JPG, faisaient échouer l’upload.
Le passage à Claude
On a ensuite ajouté Claude d’Anthropic à côté d’OpenAI, avant d’en faire le fournisseur par défaut. On a choisi Claude Haiku 4.5 : il est rapide, peu coûteux, et largement suffisant pour reconnaître des objets dans une photo.
Le parcours d’une photo est maintenant plus simple.
1. La photo est d’abord normalisée : on corrige la rotation, on la réduit à 1 568 px maximum de côté et on la convertit en JPEG.
2. Elle est ensuite envoyée directement à Claude dans un seul appel.
3. Le modèle renvoie une liste d’objets au format JSON.
4. L’utilisateur relit, corrige et valide les propositions.
Le changement a surtout permis de simplifier le flux. L’image part directement dans le message, sans upload préalable. Et comme le fournisseur reste un paramètre, on peut revenir sur OpenAI pour comparer sans devoir toucher au code.
L’analyse de photo pour les inventaires
Le plus gros du travail n’a pas été de brancher le modèle. Ça, c’est relativement rapide. Le vrai travail a été de lui faire produire un inventaire exploitable.
Au début, il listait les fenêtres, les portes, les radiateurs. Or ce ne sont pas des biens mobiliers : on ne veut pas inventorier la structure du bâtiment. On a donc précisé que seuls les objets mobiles devaient apparaître.
Il inventait aussi des objets plausibles, mais absents de la photo. La consigne est maintenant simple : ne lister que ce qui est visible, et laisser de côté en cas de doute. On utilise aussi une température à zéro pour avoir des réponses plus stables.
Un autre problème concernait la précision des noms. Le modèle pouvait écrire « manette de jeu » alors qu’on attend plutôt la marque et le modèle du produit. Il doit donc lire les logos et les étiquettes visibles pour donner un nom plus précis.
Les objets identiques étaient parfois répétés. Quatre chaises devenaient quatre lignes distinctes. Maintenant, ils sont fusionnés et la quantité est comptée.
Les prix étaient également trop génériques. Le modèle doit aujourd’hui proposer un prix neuf en CHF, TVA incluse, en se basant sur la marque et le modèle, avec des repères de revendeurs suisses.
Enfin, les catégories libres posaient problème pour le filtrage. Le modèle doit maintenant choisir dans une liste fixe.
Deux réglages importants
Deux réglages ont aussi fait une vraie différence.
D’abord, la résolution. On a fixé la taille maximale à 1 568 px de côté. En dessous, les marques et les modèles devenaient difficiles à lire. Au-dessus, on payait pour une précision qu’on n’utilisait pas vraiment.
Ensuite, la recherche web. On a essayé de la laisser active côté Claude pour fiabiliser les prix. Puis on l’a limitée à une seule recherche. Finalement, on l’a retirée : les résultats alourdisaient trop les requêtes et on dépassait la limite de débit. Aujourd’hui, le prix reste une estimation du modèle, que l’utilisateur peut corriger.
L’OCR de carte grise
Pour les véhicules, le traitement se fait en plusieurs étapes.
1\. Google Document AI lit le document scanné et en extrait le texte brut.
2\. Le modèle de langage transforme ce texte en champs structurés.
3\. Notre code vérifie et normalise chaque valeur.
4\. Le formulaire du véhicule est pré-rempli, prêt à être relu.
On a gardé l’OCR comme outil dédié, parce qu’il lit les documents de façon fiable. Le modèle ne sert qu’à comprendre et organiser ce texte.
Les consignes tiennent compte de la carte grise suisse. Chaque case est associée à un champ précis : D.2 pour la marque et le modèle, E pour le numéro de châssis, la première mise en circulation, la réception par type, les expertises, etc. Le modèle renvoie aussi des valeurs exactes pour la catégorie, le carburant ou la transmission.
Le code repasse derrière pour vérifier ce que le modèle ne garantit pas. Les dates au format suisse sont converties, le numéro de châssis est mis en majuscules, et chaque valeur est contrôlée contre une liste autorisée. Si la réponse est mal formée, on essaie de la récupérer. Sinon, l’utilisateur reçoit un formulaire vide avec un avertissement.
Ce qu’on en tire
Le principe de base reste simple : l’IA propose, l’utilisateur valide. Un inventaire faux coûte plus cher qu’un inventaire lent.
La plupart des consignes n’ont pas été écrites d’un coup. Elles sont venues d’erreurs réelles, corrigées photo après photo.
On a aussi appris à ne pas faire confiance au modèle pour tout. Les dates, les valeurs autorisées et le format de la réponse sont vérifiés en code.
Garder le fournisseur interchangeable a été utile. C’est ce qui a rendu le passage de GPT-4o à Claude simple.
Et enfin, un modèle plus petit suffit souvent. Haiku fait le travail. La qualité vient surtout des consignes et de la résolution de l’image, pas de la taille du modèle.
Plus de Thomas Burkhalter
Un LLM pour lire des demandes de transport : retour d'expérience Mistral × Infomaniak
Chez notre client, un parser à regex lisait mal les remarques libres des demandes de transport (fauteuil, aide à la marche) et se cassait dès qu’une colonne changeait. On l’a complété par Mistral hébergé chez Infomaniak. Le LLM ne décide jamais seul : il peut seulement ajouter des besoins, ses réponses sont validées en code, et on retombe sur les regex en cas d’échec. Résultat : 48 corrections justifiées sur un mois, pour environ 0,15 CHF grâce au cache. Leçons principales : un simple dictionnaire d’en-têtes a suffi pour les colonnes, et seul un garde-fou en code a stoppé les hallucinations.
5 min de lecture
