On ne livre pas des principes. On livre des systèmes. Mais les principes sont la raison pour laquelle nos systèmes se comportent comme ils le font.
Dans les boîtes avec lesquelles on travaille, le logiciel n'est pas un enabler. C'est l'opération elle-même. Un POS lent un vendredi soir, ce n'est pas un problème d'UX — c'est un problème business. On conçoit et on construit en gardant ce poids en tête dès la première ligne. L'équipe qui tient la salle utilise ce qu'on livre à chaque service ; le client qui commande l'utilise tous les jours. Le poli, c'est pour les surfaces. Nous, on dimensionne pour la charge.
La plupart des projets cassent aux coutures. L'app mobile qui n'est pas tout à fait d'accord avec le backend. La couche IA qui ne se réconcilie pas avec la source de vérité. Les intégrations qui se collent au scotch. On bosse end-to-end par choix — web, mobile, API, IA, data — même équipe, même tête. Moins de coutures. Moins de surprises. Une des raisons pour lesquelles un ERP restaurant multi-plateforme peut tourner dans 4 établissements sur deux pays depuis 2020.
Certains de nos systèmes tournent dans des endroits où la connectivité est un vœu, pas une garantie. Offline-first, pour nous, ce n'est pas un buzzword — c'est la raison pour laquelle certains de ces systèmes sont toujours vivants. Le mini-PC sous Linux sur le réseau local. Les commandes smartphone qui se synchronisent localement et qui partent en batch vers le cloud plus tard. La couche online robuste pour les propriétaires. On conçoit pour le mauvais jour. Le bon jour s'occupe de lui-même.
On ne livre pas des features IA qui marchent « la plupart du temps ». Quand l'IA est dans un ERP qui gère 5M+$/semaine, « la plupart du temps » n'est pas une valeur. Modèles locaux quand ça a du sens, retrieval vectoriel pensé autour de la vraie donnée, caching, validation mathématique, outputs doublement vérifiés. Le LLM propose ; le système réconcilie avant que quoi que ce soit arrive chez un client. Le standard, ce n'est pas « ça a l'air impressionnant ». Le standard, c'est « tu peux agir dessus ».
Chaque système qu'on livre doit cohabiter avec la boîte qu'il sert. Ça veut dire des modes de panne clairs, du vrai monitoring, des défauts sains, un comportement observable, et du code que quelqu'un — y compris nous — peut encore lire dans trois ans. Un repo joli qui pète au sixième mois, ce n'est pas une victoire. On optimise pour ce qui tourne encore en 2029, pas pour ce qui a fière allure au launch.
Les systèmes dont on est le plus fiers tournent toujours. Cinq ans après. Zéro churn sur le travail long terme côté restaurant. Le chemin le plus court vers du bon logiciel est généralement un long chemin — et on préfère bosser avec des gens qui pensent à cette échelle plutôt qu'avec des gens qui veulent un système qu'on pourra arracher au prochain trimestre.
Si c'est comme ça que votre opération doit être construite,
on devrait probablement se parler.
