Du vrai volume. De vraies boîtes. De la vraie production.
La majorité de ce qu'on construit vit à l'intérieur d'opérations qui ne sont pas grand public. Les noms restent privés. Les chiffres, le scope et les contraintes, non.
Pipeline IA livré dans un ERP en production.
ScopeArchitecturer et livrer toute la couche IA dans un ERP existant qui sert 70+ entreprises.
ContexteOn n'a pas construit l'ERP. C'est l'équipe qui l'avait construit qui nous a fait venir, parce que leurs clients avaient besoin d'une vraie couche IA capable de tourner sur de la donnée réelle — pas d'un chat collé par-dessus. Ils nous ont fait confiance pour architecturer, construire et livrer ça de bout en bout.
d'opérations clients qui passent désormais par la couche.
Un vrai pipeline d'ingestion qui prépare la donnée production de chaque client pour la retrieval — sur la forme réelle de leur boîte, pas un schéma générique. Cas limites et incohérences gérés dans le code, pas refilés au LLM.
Architectures de retrieval pensées autour du modèle de données de l'ERP. Vectorisation tunée par classe de donnée. Requêtes réconciliées contre la source de vérité avant génération, pas après.
Une couche de cache pour que le système ne paie pas deux fois la même pensée. Vectorisation batchée et persistée pour garder la latence prédictible sous charge.
Les outputs qui touchent à de la finance, de l'opération ou du stock sont vérifiés contre la donnée sous-jacente programmatiquement avant qu'ils quittent le système. Le LLM propose, le système vérifie.
Les managers demandent un rapport custom, en langage naturel, sur leur propre donnée. Le système le produit — formaté, validé, réconcilié. En production, par entreprise.
Le résultat, c'est un manager automatique en qui 70+ entreprises — et 5M+$/semaine de leurs opérations — ont réellement confiance pour tourner. Pas un wrapper d'API. Un système.
Le backbone complet d'une parfumerie de niche.
ScopeConcevoir et livrer toute la stack opérationnelle de zéro — ERP interne, POS sur-mesure, application client de commande.
ContexteUn acteur niche du retail avait besoin d'un système cohérent unique. POS tout-fait, ERP tout-fait, ordering tout-fait — aucun ne se parlait, aucun ne collait au flux réel de vendre du parfum. On a construit un système avec trois interfaces à la place.
d'opérations qui tournent sur le système aujourd'hui.
Inventaire, fournisseurs, bons de commande, mouvements de stock, gestion employés. Un backend, un schéma. Construit pour les équipes qui l'utilisent au quotidien, pas pour la démo.
Pensé autour de la vraie chorégraphie d'une vente de parfum — échantillonnage, multi-articles, emballage cadeau, reconnaissance client — pas un script retail générique.
Les clients commandent, les équipes traitent, le stock se décrémente en temps réel. Même source de vérité. Pas de job de réconciliation qui tourne la nuit.
Un backend. Trois interfaces. Une source de vérité. Le but n'était pas de livrer trois apps — c'était de faire un seul système qui se comporte comme un seul système, du stock à la caisse au téléphone du client.
ERP restaurant sur deux pays, depuis 2020.
ScopeSystème opérationnel de bout en bout pour un groupe d'hôtellerie — multi-plateforme, multi-modal, offline-first, online côté propriétaires.
ContexteLive dans 4 restaurants sur deux pays avec une connectivité peu fiable. Cette contrainte a structuré chaque choix d'architecture. Le système tourne, que l'internet tourne ou pas.
depuis le lancement en 2020. 4 établissements toujours en service.
Un petit mini-PC headless sous Linux fait office de serveur local dans chaque établissement, gardant la source de vérité sur le réseau local. Survit aux coupures. Fait tourner la salle.
Les serveurs prennent les commandes sur leur téléphone, qui partent directement en cuisine et au bar. Multi-device, multi-étage, tout synchronisé localement sur le POS central.
Les tickets s'impriment automatiquement à la bonne destination — caisse, bar, cuisine — selon le produit. Pas de double traitement. Pas de routage manuel par les équipes au moment du rush.
Le stock se décrémente à chaque commande, sur chaque device. La réconciliation de fin de service n'est pas un job ; elle est déjà faite.
Tout tourne sur le réseau local, avec ou sans internet. Commandes, paiements, impressions. La connectivité est un mécanisme de sync, pas un prérequis pour faire tourner.
Une couche online robuste batche la donnée locale vers le cloud à intervalle régulier. Les propriétaires regardent revenus, recettes et performance en direct sur tous leurs établissements quand ils sont connectés.
Un des systèmes dont on est le plus fiers — pas parce que c'est le plus gros, mais parce qu'il tourne toujours. Cinq ans plus tard. Zéro churn. Dans les conditions pour lesquelles il a été construit.
Plus petits. Même principe.
À côté des projets phares, on a livré plusieurs systèmes opérationnels plus petits pour des SMB — dashboards internes, workflows custom, intégrations entre outils qui ne se parlaient pas. Différents scopes. Même principe : du logiciel qui fait tourner la boîte, pas du logiciel posé à côté.
Gestion long terme du digital.
Des contrats actifs avec plusieurs boîtes — présence web, outils internes, évolutions mensuelles. 4+ sites en production livrés en chemin sur retail et hôtellerie.
Le genre de relation où vous n'avez pas à ré-expliquer votre métier tous les trimestres.
Vous avez quelque chose de similaire dans vos opérations ?