MexarComment savoir si votre entreprise a besoin d’un logiciel sur mesure ?
La réponse se construit avec un essai sur votre travail réel. Prenez un processus limité, définissez le résultat attendu, puis vérifiez ce que couvrent le paramétrage, un outil existant ou une intégration. Le sur-mesure devient une option quand un écart important persiste et que sa résolution peut justifier l’investissement complet.
Par François Aubeut, fondateur de Mexar ·
Délimiter un essai qui peut conclure
Évitez un objectif comme « centraliser toute l’entreprise ». Choisissez une opération dont vous pouvez montrer l’entrée et la sortie : traiter une demande de modification, préparer un rapport ou faire valider une intervention.
Écrivez un critère observable. Par exemple : « un collègue habilité peut retrouver la version approuvée et comprendre qui l’a validée ». L’essai peut alors réussir ou révéler un manque précis. Le nombre d’écrans n’est pas un critère de réussite.
Le protocole de vérification
Observer un cas normal et un cas difficile
Faites exécuter le travail par les personnes concernées. Relevez les règles, les sources et les passages de relais. Ne remplacez pas leur pratique par le processus idéal d’un document.
Écrire les exigences indispensables
Séparez obligation métier et préférence d’interface. Pour chaque exigence, indiquez un exemple d’entrée et le résultat qui permet de la vérifier.
Tester l’existant
Demandez une démonstration du paramétrage ou du module déjà disponible. Si cela suffit, documentez la configuration et le temps de prise en main.
Éprouver une alternative
Examinez un outil du marché ou une connexion sur le même scénario, avec les mêmes droits, formats et exceptions. Un écran de présentation ne prouve pas que votre scénario passe.
Isoler l’écart résiduel
Décrivez la fonction ou la règle qui manque encore, sa conséquence et l’effort de contournement. Le futur développement doit répondre à cet écart.
Décider et garder la preuve
Conserver, configurer, connecter ou construire : consignez la raison, les réserves et le responsable. Une décision de ne pas développer est un résultat valable.
Le journal d’essai
| Scénario | Preuve attendue | Conclusion à noter |
|---|---|---|
| Demande complète | La demande passe toutes les étapes et produit le résultat défini. | Réussi, échoué ou non testé, avec la raison. |
| Pièce manquante | Le défaut est signalé et le dossier peut reprendre sans perte. | Qui corrige et quelle trace reste disponible. |
| Droit insuffisant | Une personne non habilitée ne peut pas effectuer l’action interdite. | Le contrôle est vérifié, pas supposé. |
| Échange indisponible | Le dossier garde un statut compréhensible si un service ne répond pas. | Comment détecter, reprendre ou traiter manuellement. |
| Reprise par un collègue | Une autre personne peut retrouver et poursuivre le dossier. | Les explications ou accès qui manquent encore. |
Faire un essai sans exposer les données
Préparez des dossiers fictifs qui reproduisent les formats et les exceptions utiles. Pour les données personnelles, la CNIL recommande des environnements séparés de la production et des jeux de test fictifs ou anonymisés. Un essai de logiciel n’autorise pas à transmettre librement un fichier client à un service tiers.
Vérifiez les formats d’entrée et de sortie. Si une intégration est envisagée, demandez l’accès à sa documentation et identifiez qui peut autoriser la connexion. Une possibilité annoncée ne vaut pas une preuve de fonctionnement dans votre environnement.
Le dossier de décision en une page
Ces cases ne sont ni enregistrées ni envoyées. Elles servent uniquement à votre lecture.
Pour chiffrer les scénarios, commencez par la méthode d’estimation. Pour arbitrer entre les réponses possibles, retrouvez les quatre voies de choix.
Sources et périmètre
Sources primaires consultées le 24 octobre 2026. Les grilles et exemples de cette page sont des outils pédagogiques proposés par Mexar, pas des seuils officiels.