Choisir un outil numérique à partir du besoin réel, pas de la liste de fonctions

Séparer besoins indispensables, confort et hypothèses

Les exigences indispensables protègent le résultat : accès par les profils prévus, recherche, correction, export, continuité ou confidentialité. Les éléments de confort améliorent l’usage mais peuvent être négociés. Les hypothèses doivent être testées : volume futur, nombre d’utilisateurs, fréquence, intégration ou besoin hors ligne.

Donnez à chaque critère un seuil et une méthode de vérification. “Simple” devient un parcours réalisable sans aide ; “sécurisé” devient une liste de contrôles adaptés ; “compatible” devient un format et une version effectivement importés. Une pondération n’est utile que si les critères restent compréhensibles et si un échec rédhibitoire ne peut pas être compensé par des options décoratives.

La liste doit rester courte. Dix critères réellement testés donnent une décision plus solide qu’une grille de cent cases copiée depuis des brochures.

Comparer les familles de solutions avant les marques

Une procédure papier, un tableur, un dossier partagé, une application spécialisée, une suite généraliste et un développement sur mesure n’ont pas les mêmes coûts ni les mêmes frontières. Le papier fonctionne sans batterie mais se partage mal ; le tableur est flexible mais dépend de règles disciplinées ; une application spécialisée apporte un modèle métier mais impose son périmètre ; une suite large mutualise des fonctions au prix d’une configuration plus lourde.

Le développement sur mesure devient pertinent lorsqu’un besoin différenciant, stable et maintenable ne peut pas être couvert autrement. Il oblige à financer la sécurité, l’accessibilité, les sauvegardes, les mises à jour et la continuité, pas seulement le premier écran.

Comparez au moins une option de continuité : garder l’outil actuel avec une procédure corrigée. Cette référence évite de présenter tout changement comme un gain automatique.

Vérifier les données avant les écrans

Listez les données nécessaires, celles qui sont sensibles, celles qui changent et celles qui doivent être exportées. La CNIL rappelle le principe de minimisation : collecter seulement ce qui est adéquat, pertinent et nécessaire. Une solution qui exige davantage d’informations doit justifier chaque champ par une finalité.

Demandez dans quel format les données entrent et sortent, comment une correction est propagée, qui peut exporter, ce qui est supprimé lors d’un départ et comment une sauvegarde est restaurée. Un bouton “exporter” qui produit un fichier incomplet ou inexploitable ne constitue pas une stratégie de sortie.

Les rôles sont testés avec des refus : un lecteur ne modifie pas, un intervenant ne voit pas un dossier étranger, un ancien membre perd ses accès. La sécurité ne se résume pas à une page de connexion.

Tester le travail ordinaire et les exceptions

Le test utilise des données fictives représentatives et les appareils réellement prévus. Il exécute création, recherche, correction, absence d’information, erreur, export et reprise après interruption. Il mesure le nombre d’étapes, les ressaisies, les décisions ambiguës et le temps de récupération.

L’accessibilité se vérifie au clavier, au zoom, avec des contrastes suffisants, des libellés explicites et un ordre de lecture cohérent selon WCAG 2.2. Sur mobile, aucune action essentielle ne dépend d’un survol. Une démonstration conduite par le vendeur ne remplace pas l’essai autonome du profil utilisateur.

Le test documente ce que l’outil ne couvre pas. Une limite visible peut être gérée par une procédure ; une limite cachée devient un incident futur.

1. Préparer trois scénarios réels et un scénario d’échec.
2. Créer uniquement des données fictives autorisées.
3. Faire agir les profils concernés sans assistance du démonstrateur.
4. Tester refus, correction, export et reprise.
5. Noter temps, erreurs, contournements et questions.
6. Comparer avec la situation actuelle selon les mêmes critères.

Calculer le coût complet sans inventer un retour sur investissement

Le prix affiché n’est qu’une composante. Ajoutez paramétrage, migration, formation, équipements, options, stockage, support, intégrations, temps d’administration et sortie. Un service gratuit peut coûter du temps ; un abonnement plus cher peut réduire certaines tâches sans garantir un gain global.

Distinguez coût certain, coût variable et hypothèse. Une économie de temps devient crédible seulement après mesure sur un parcours comparable. N’attribuez pas à l’outil un résultat dépendant d’un changement d’organisation, d’une nouvelle donnée ou d’un partenaire non acquis.

Fixez un budget de sortie et une durée de décision. L’absence de prix public est une donnée manquante, pas une invitation à estimer un tarif.

Décider, documenter et revoir

La décision reprend le besoin, les options écartées, les critères, les preuves, les limites acceptées et les conditions de retour. Un pilote borné précède la généralisation lorsque le risque ou le coût le justifie. La version précédente reste disponible en lecture ou comme rollback pendant la période définie, sans doubles écritures concurrentes.

La revue est planifiée après quelques semaines d’usage réel puis à chaque changement important de prix, de périmètre, de fournisseur ou de réglementation. Elle vérifie si le problème initial est mieux traité, pas si toutes les fonctions sont utilisées.

DOHM et ses applications peuvent être évalués avec cette même grille. Ils ne reçoivent ni bonus éditorial ni critère réservé. Le présent guide reste utilisable sans choisir une solution DOHM.

Limites

Aucune grille ne remplace l’expérience des personnes concernées, une analyse juridique ou un audit de sécurité proportionné. Les besoins peuvent évoluer ; la décision doit donc conserver ses hypothèses et sa date.

Un outil pertinent pour une équipe peut être inadapté à une autre. La simplicité dépend des profils, du contexte et de la fréquence d’usage ; elle se démontre par un parcours, elle ne se déduit pas d’un slogan.