Jay Did Nous voyons régulièrement des entreprises abandonner un logiciel six mois après l'avoir acheté. Rarement parce qu'il était mauvais. Presque toujours parce qu'il avait été conçu pour un contexte qui n'est pas le leur.
Voici les cinq écarts que nous rencontrons le plus souvent.
1. Le logiciel suppose une connexion permanente
Beaucoup d'applications modernes sont entièrement dépendantes du réseau : sans connexion, l'écran se fige. C'est un choix défendable dans un bureau relié en fibre redondée. Il l'est beaucoup moins pour une boutique, un entrepôt ou un hôtel où la liaison tombe plusieurs fois par semaine.
La question à poser en démonstration n'est pas « est-ce que ça marche hors ligne ? » — la réponse commerciale est toujours oui. Demandez plutôt : que se passe-t-il exactement si je coupe la connexion en pleine saisie ? Puis faites-le, pendant la démonstration.
2. Les moyens de paiement locaux ne sont pas prévus
Un logiciel de caisse qui ne gère que la carte bancaire est inutilisable là où l'essentiel des transactions se fait en espèces et par paiement mobile. Ajouter ces moyens après coup est rarement une simple configuration : cela touche à la comptabilité, au rapprochement et aux états de clôture.
Vérifiez aussi le traitement du franc CFA : arrondis, absence de décimales dans l'usage courant, et affichage des montants. Un logiciel qui impose deux décimales partout produit des tickets que personne ne lit correctement.
3. Le support est sur un autre fuseau horaire
Un éditeur dont le support ouvre à 9 h en Europe centrale répond à partir de 8 h à Lomé — ce qui reste acceptable. Un éditeur nord-américain répond à partir de 14 h ou 15 h. Si votre caisse tombe le samedi matin en pleine affluence, la différence n'est pas théorique.
Demandez les horaires réels, le délai d'engagement contractuel, et surtout : dans quelle langue et par quel canal ? Un support par formulaire web avec réponse sous 48 heures n'est pas un support pour un système de production.
4. Le modèle de données ne correspond pas aux pratiques
C'est l'écart le plus coûteux, parce qu'il n'apparaît qu'après le déploiement. Quelques exemples réels :
- un logiciel hôtelier qui n'accepte qu'un seul titulaire par réservation, dans un marché où la réservation de groupe familial est la norme ;
- un système de facturation qui exige un numéro de TVA pour chaque client, alors qu'une grande partie de la clientèle relève de l'informel ;
- une gestion de stock qui refuse les quantités décimales, inutilisable pour tout ce qui se vend au poids ou au volume.
Ces contraintes sont inscrites dans le modèle de données. Les contourner demande une modification du cœur du logiciel, ce qu'un éditeur étranger n'acceptera pas pour un client isolé.
5. Personne n'a prévu la reprise des données
Vos données existent déjà : dans un tableur, dans l'ancien logiciel, dans des cahiers. Le coût et le délai de leur reprise sont presque toujours sous-estimés, et cette étape est celle qui fait dérailler les calendriers.
Avant de signer, exigez une reprise de test sur un échantillon réel — vos vraies données, pas un jeu de démonstration. Vous découvrirez en quelques heures ce que vous auriez sinon découvert en trois mois.
Comment nous conduisons ce choix
Nous demandons systématiquement une démonstration menée avec les données du client et par les utilisateurs finaux, pas par le commercial. Une caissière qui saisit dix ventes réelles révèle en vingt minutes ce qu'aucun cahier des charges ne capture.
Et quand aucun logiciel du marché ne correspond, l'alternative n'est pas nécessairement le développement sur mesure intégral : souvent, un outil existant complété d'un module spécifique coûte trois fois moins cher et se déploie deux fois plus vite.