Application scanner : un seul produit, N configurations
25 juillet 2026
Le piège du scanner « simple »
Une application de scan a l'air triviale : on lit un code-barres, on affiche un produit. Puis les cas réels arrivent.
Un magasin scanne des EAN-13 classiques. Un autre utilise des codes internes préfixés. Un troisième pèse ses articles et travaille avec des codes-barres embarquant un poids variable. Un quatrième veut refuser tout code qui ne figure pas dans son référentiel ; un cinquième veut au contraire créer la fiche à la volée.
La réponse habituelle est de dupliquer l'application par client. Au bout de trois versions, chaque correction doit être appliquée trois fois, et l'une des trois sera oubliée.
Le choix : configurer, pas forker
Pour Inopos, nous avons pris le problème dans l'autre sens : une seule application, dont le comportement est décrit par une configuration.
Ce qui se règle sans toucher au code :
- Les types de scan acceptés : EAN-13, EAN-8, Code 128, QR, ou un sous-ensemble par point de vente.
- Les règles de validation : code inconnu accepté, refusé, ou mis en attente de contrôle.
- La gestion des préfixes : reconnaître un code interne, en extraire la partie utile, ignorer le reste.
- Le parcours après scan : quantité, prix, contrôle visuel, ou validation immédiate.
Résultat : déployer chez un nouveau client, c'est écrire une configuration, pas ouvrir une branche.
Ce que ça change en production
Un seul binaire à maintenir. Une correction de bug profite immédiatement à tous les points de vente. Pas de matrice de versions à suivre.
Les tests deviennent utiles. Comme les variantes sont des données et non du code, on peut tester les combinaisons de règles sans multiplier les scénarios d'intégration.
Le déploiement client se compte en minutes. L'installation ne demande plus un développeur : le paramétrage est éditable par l'équipe qui connaît le magasin.
Les décisions techniques qui comptent
Traiter la configuration comme un contrat. Elle est validée au chargement, avec un schéma explicite. Une configuration incorrecte échoue immédiatement, avec un message clair, pas trois écrans plus loin, au milieu d'un inventaire.
Prévoir le hors-ligne dès le départ. Un magasin a des zones sans réseau. Les scans sont enregistrés localement puis synchronisés ; l'utilisateur n'a rien à comprendre à ça.
Ne pas rendre configurable ce qui ne varie pas. Chaque option ajoutée est une combinaison de plus à tester. On n'ouvre un réglage que lorsqu'un deuxième client en a réellement besoin.
Optimiser le geste, pas l'écran. En rayon, l'utilisateur scanne d'une main. Le nombre de touches après un scan compte plus que l'esthétique de l'interface.
Est-ce que ça vaut le coup pour vous ?
Ce modèle a du sens si vous prévoyez de déployer la même application dans plusieurs contextes légèrement différents : plusieurs enseignes, plusieurs sites, plusieurs métiers.
À l'inverse, pour un usage unique et stable, la configuration ajoute de la complexité sans contrepartie. Une application figée est alors plus simple à écrire et à maintenir.
Vous pouvez voir le résultat sur la page application scanner. Un projet du même ordre ? Écrivez-nous.