Construire pour le terrain, pas pour la démo
Pourquoi un produit qui marche en démo s'effondre face à la connectivité intermittente, et ce que nous faisons à Solis pour y résister.
Une démo réussie est un mensonge poli. Elle se déroule sur un réseau stable, avec un utilisateur unique, sur un jeu de données propre. Le terrain, lui, est instable, pluriel et sale. C'est la raison pour laquelle la plupart des produits qui brillent en présentation s'effondrent à la première vraie utilisation.
La connectivité n'est pas un détail
En RDC comme dans une grande partie de l'Afrique subsaharienne, la connexion n'est pas garantie. Un produit qui suppose un réseau permanent est un produit qui ne marche pas. Chez Solis, nous concevons systématiquement pour le mode dégradé : stockage local, synchronisation différée, reprise automatique.
Un système qui perd les données d'un utilisateur parce que le réseau a coupé n'est pas un système. C'est un incident en attente.
Concevoir pour l'utilisateur réel, pas pour le décideur
Celui qui valide l'achat n'est pas celui qui utilise l'outil chaque jour. L'agent de terrain, le professeur, l'infirmier — leurs contraintes comptent plus que les préférences du comité de pilotage. Nous passons du temps avec les utilisateurs finaux avant d'écrire la première interface.
C'est cette discipline qui distingue un produit de terrain d'une maquette. Et c'est elle qui fait qu'un produit Solis reste en service trois ans après sa livraison.