Quotery en 2026 — ce qui a été livré, ce qui s’annonce

Il s’agit du vingtième article de ce blog. Il m’a paru approprié d’écrire quelque chose de différent — non pas une analyse détaillée d’une fonctionnalité, mais un rapport d’état honnête sur la situation du produit, ce qui a été livré, ce qui ne l’a pas été, et la direction que nous prenons.

Ce qui a été livré cette année L’importateur de documents à base d’IA est la réalisation marquante. Il a remplacé un importateur rigide, limité à Excel, présent depuis les toutes premières versions de la plateforme. L’ancien importateur ne fonctionnait que si le fichier de l’expéditeur correspondait exactement à la disposition de colonnes attendue — toute déviation, toute colonne supplémentaire, tout nom d’en-tête légèrement différent, et l’importation échouait avec une erreur sibylline. L’importateur à base d’IA accepte le PDF, le XLSX, le XLS et le CSV, s’adapte à la disposition que le client utilise, et classe chaque ligne comme correspondance exacte, décision de l’IA ou introuvable. Les premières importations de clients réels ont validé le pari central : un pipeline enrichi par un LLM pouvait absorber le désordre des documents réels des clients sans exiger qu’ils modifient leur format.

En parallèle de l’importateur, nous avons achevé la couverture trilingue de l’interface pour chaque nouvelle surface. La plateforme sert désormais en-US, pt-BR et es-US sur l’ensemble des pages — non seulement dans les flux de devis et de stock, mais dans chaque écran de paramètres, chaque message d’erreur, chaque boîte de dialogue de confirmation et chaque modèle d’e-mail. Le système de traduction fonctionne comme une infrastructure d’intégration continue : une étape de build vérifie que chaque fichier de locale contient chaque clé présente dans la base en-US, et toute clé manquante fait échouer le build. Fini le « cette chaîne est uniquement en anglais parce que nous avons oublié de l’ajouter aux autres fichiers ».

Le registre des mouvements de stock a été livré comme pièce fondatrice du système de gestion du stock. Chaque évolution du stock — réservation (reserve), libération (release), expédition (ship), retour (return), réception (receive), ajustement (adjustment) — est enregistrée comme un mouvement typé avec une variation signée, une clé étrangère vers le document source, un horodatage et l’utilisateur à l’origine de l’opération. Ce registre est en écriture seule : les lignes ne sont jamais modifiées, jamais supprimées. Le cache stocke le solde courant ; le registre constitue l’enregistrement durable. N’importe quelle équipe peut auditer l’historique complet de n’importe quel produit, en n’importe quel lieu, sans demander à l’ingénierie d’exécuter une requête.

Trois documents de traçabilité — DeliveryNote, ReturnNote et StockReceipt — partagent désormais un flux de comptabilisation unique. L’enregistrement d’une livraison fait passer le stock de réservé à expédié. Celui d’un retour le fait repasser d’expédié à disponible. Celui d’une réception comptabilise le stock entrant chez un fournisseur. Les trois créent des mouvements de stock avec l’identifiant du document dans la clé étrangère source, les trois mettent à jour le même cache, et les trois respectent les mêmes limites de permissions. Ce flux partagé permet aux équipes d’entrepôt d’apprendre un seul schéma, et non trois.

La matrice des permissions a résisté à l’examen. Quatre groupes — admin, manager, commercial, warehouse — avec une matrice documentée indiquant qui peut créer, lire, modifier ou supprimer quoi. Pas de dérogations par locataire, pas d’ACL par utilisateur, pas de classes de permission personnalisées éparpillées dans les vues. Les nouvelles fonctionnalités commencent par l’ajout d’une ligne à la matrice, puis le câblage du contrôle. La simplicité est la fonctionnalité : lorsqu’un client demande « qui peut approuver un retour ? », la réponse se trouve dans un unique tableau markdown, et non dispersée dans six fichiers.

Le blog que vous lisez actuellement a été lancé avec la refonte du site marketing. Vingt articles couvrant les décisions techniques derrière le produit — non pas des textes publicitaires, mais des explications honnêtes de la raison pour laquelle la plateforme fonctionne comme elle le fait. Le blog est à la fois une surface de référencement et un signal de crédibilité technique : un client potentiel qui lit trois articles en sait davantage sur la manière dont Quotery gère le stock qu’il n’en apprendrait au cours d’une douzaine de démonstrations de concurrents.

Ce qui n’a pas été livré Nous voulions livrer un module de rapports — tableaux de bord avec tendances des ventes, rotation du stock, taux de conversion des devis. Cela ne s’est pas fait. L’importateur a consommé plus de temps d’ingénierie que prévu, et nous avons fait le choix délibéré de livrer une chose de manière aboutie plutôt que deux choses à moitié. Le modèle de données des rapports est conçu et les requêtes sont écrites ; il manque la surface front-end. C’est la première priorité du prochain cycle.

Les intégrations comptables restent au programme. La plateforme peut exporter des données dans des formats consommables par les outils comptables, mais il n’existe aucune intégration directe par API avec un progiciel comptable. C’est en partie technique — les API comptables sont notoirement incohérentes — et en partie un choix de séquencement : intégrer un outil que vous n’utilisez pas encore au quotidien serait prématuré. Maintenant que les flux de base sont solides et que les clients sont en production, les intégrations deviennent la couche naturelle suivante.

L’optimisation mobile pour les flux d’entrepôt est partielle. La plateforme est réactive et fonctionne sur un téléphone, mais l’expérience d’entrepôt — scannage, préparation de commandes, comptabilisation des livraisons — a été conçue pour un navigateur de bureau. Une vue d’entrepôt dédiée, conçue pour le mobile d’abord, optimisée pour le scan de codes-barres et pour l’usage à une seule main, constitue le troisième grand élément du programme.

Ce qui s’annonce Le module de rapports vient en premier. L’objectif n’est pas un tableau de bord d’analyse générique doté d’une douzaine de widgets que personne n’utilise. Ce sont trois vues ciblées : performance des ventes (volume de devis, taux de conversion, chiffre d’affaires par client et par produit), santé du stock (rotation, stock mort, fréquence des ruptures) et activité de l’équipe (devis créés, livraisons comptabilisées, retours traités par utilisateur). Chaque vue possède un graphique principal, un tableau de synthèse et un bouton d’export. Le principe de conception est le même que celui appliqué à l’importateur : répondre d’abord à la question la plus importante, puis se faire discret.

Les intégrations comptables suivent. Nous évaluons quel progiciel intégrer en premier, en fonction de la demande des clients et de la qualité des API. L’intégration sera d’abord unidirectionnelle — Quotery envoie les factures et les valorisations de stock au système comptable, mais n’en tire pas de données en retour. La synchronisation bidirectionnelle est un problème plus délicat (résolution des conflits, propriété des données, réconciliation) et nous préférons livrer une intégration unidirectionnelle fiable plutôt qu’une intégration bidirectionnelle peu fiable.

La vue mobile d’entrepôt est le troisième grand élément. Il ne s’agit pas d’une application mobile — c’est une vue web réactive optimisée pour les contraintes ergonomiques propres au travail en entrepôt. De larges zones tactiles pour les mains gantées, le scan de codes-barres via la caméra de l’appareil, une navigation au pouce et une comptabilisation tolérante hors connexion (mise en file de l’enregistrement, synchronisation au retour de la connectivité). La vue d’entrepôt sur ordinateur demeure réservée au travail en back-office ; la vue mobile est destinée au personnel sur le terrain.

Au-delà des trois grands éléments, il reste une longue traîne de finitions. La restauration de la position de défilement lors de la navigation. Des raccourcis clavier pour les utilisateurs avancés — clôturer un devis, comptabiliser une livraison, approuver un retour, tout depuis le clavier. De meilleurs messages d’erreur dans des cas limites difficiles à atteindre, mais déroutants lorsqu’ils surviennent. Des gabarits de chargement correspondant à la forme du contenu qu’ils remplacent. Ce ne sont pas des éléments de programme assortis d’échéances ; c’est un travail continu qui se déroule entre les fonctionnalités. Les détails discrets qui séparent un logiciel que l’on tolère d’un logiciel auquel on se fie.

Ce que nous avons appris La plus grande leçon de l’année : les fonctionnalités d’IA réussissent ou échouent par leur expérience de relecture, et non par la précision du modèle. Le LLM de notre importateur est bon — il classe correctement environ 90 % des lignes qu’il tente. Mais si le fait de valider ces 90 % ressemblait à un travail, la fonctionnalité aurait échoué. L’interface de relecture — comparaison en ligne, validation en une seule pression, hiérarchie visuelle claire — est ce qui rend la précision exploitable. Un modèle précis à 95 % assorti d’une mauvaise expérience de relecture est pire qu’un modèle précis à 85 % assorti d’une bonne expérience, car l’utilisateur passe davantage de temps à se battre avec l’interface qu’à corriger le modèle.

La deuxième leçon : les modèles de données en écriture seule valent la complexité initiale. Le registre des mouvements de stock a demandé plus de temps de conception et d’implémentation qu’une simple approche par solde courant. Mais chaque question d’audit, chaque investigation d’écart, chaque « pourquoi ce chiffre était-il différent mardi dernier ? » trouve une réponse par une requête plutôt que par une hypothèse. Le registre a déjà remboursé sa complexité en évitant des séances de débogage et en permettant des réponses assurées aux questions des clients.

La troisième leçon : le support trilingue ne représente pas trois fois le travail. Une fois l’infrastructure de traduction en place — recherches par clé, contrôle en intégration continue, formatage adapté à la locale pour les dates et les chiffres — l’ajout d’une troisième langue relève surtout d’un travail de traduction, et non d’ingénierie. La première langue après l’anglais a exigé la construction de l’infrastructure. La troisième a exigé d’écrire des chaînes en espagnol. Le coût marginal décroît fortement.

Un remerciement Aux premières équipes qui ont fait passer de véritables PDF de clients par l’importateur et nous ont dit exactement ce qui ne fonctionnait pas : merci. Votre disposition à tester un nouvel outil sur des documents réels — non pas des données de test, non pas des échantillons aseptisés, mais les PDF désordonnés que vos clients envoient réellement — est ce qui a fait la qualité de l’importateur. Chaque cas limite que nous gérons aujourd’hui (le PDF protégé par mot de passe, le scan composé uniquement d’images, le client qui utilise six formats de SKU différents sur la même page) existe parce que quelqu’un est tombé dessus et nous l’a signalé.

À tous ceux qui ont lu ces articles de blog et envoyé des retours : merci. Écrire publiquement sur des décisions techniques est un formidable vecteur de clarté. Plusieurs articles de cette série ont commencé comme des notes personnelles avant de devenir des explications que nous utilisons désormais dans les conversations commerciales et les sessions d’intégration. Le blog s’est transformé en un atout que nous n’avions pas anticipé.

Il reste encore beaucoup à construire. Le module de rapports, les intégrations comptables, la vue mobile d’entrepôt et le fini soigné qui rend le tout un peu plus solide. Mais les fondations sont réelles : l’importateur fonctionne, le registre est en écriture seule, les permissions sont simples et les traductions sont complètes. La troisième année démarre sur de bonnes bases.