Votre entreprise a‑t‑elle besoin d’un logiciel métier  ?

Un devis attend parce que la bonne version du fichier est introuvable. Une commande doit être recopiée entre deux outils. Une absence bloque une validation que personne d’autre ne sait reprendre. Ces situations méritent un diagnostic ; elles ne prouvent pas qu’il faut développer un logiciel sur mesure.

Si un problème peut compromettre significativement les droits d’accès, la restauration, l’intégrité des données ou la continuité de l’activité, évaluez le risque et sécurisez ce qui l’exige avant de choisir ou de modifier un outil. Pour le reste, notez trois situations que votre équipe a vécues. Pour chacune, indiquez le travail attendu, ce qui s’est passé, la fréquence, la conséquence, les personnes touchées et les corrections déjà essayées.

Vous pourrez alors comparer exactement six réponses: sécuriser, simplifier, mieux configurer l’existant, connecter de façon limitée, adopter un standard ou étudier une fonction sur mesure.

Lorsque les faits manquent, que l’irritation est isolée ou que les règles changent encore, observer est aussi un verdict valable. Ce n’est pas une septième solution à acheter : fixez ce qu’il faut mesurer et la date à laquelle vous réexaminerez la situation.

Avant tout choix d’outil, posez une question de continuité : l’équipe peut-elle encore travailler si un accès, une personne ou un outil manque ?

Un nouvel outil n’est pas la première réponse lorsqu’un départ, une panne ou une erreur d’accès peut rendre les dossiers indisponibles. Commencez par demander : qui possède les comptes ? qui peut restaurer la dernière version utile ? que fait l’équipe pendant l’indisponibilité ? qui reçoit l’alerte ?

Pour les traitements de données personnelles, la CNIL recommande de limiter les habilitations au besoin d’en connaître, de réexaminer les droits et d’éviter les comptes partagés sauf exception encadrée. Cela concerne d’abord les données personnelles ; la même discipline reste utile pour savoir qui peut agir sur une commande, un prix ou une validation.

Le guide de sécurité de la CNIL, version 2024 mise à jour en 2026, recommande des sauvegardes fréquentes, protégées et séparées, des tests réguliers d’intégrité et de restauration ainsi qu’une organisation de la continuité et de la reprise. La stratégie exacte dépend du risque ; cocher « sauvegarde activée » ne prouve pas que l’activité repart. Un fonctionnement dégradé doit préserver un niveau de protection adapté et prévoir le rattrapage puis le retour au fonctionnement normal.

Une impression générale comme « nous perdons beaucoup de temps » est difficile à vérifier. Choisissez plutôt trois événements ordinaires sur une période connue. Demandez à la personne qui réalise le travail de décrire le cas normal, puis ce qui a créé le blocage. N’utilisez pas uniquement la version du dirigeant ou du prestataire.

Un dossier pratique hébergé par France Num propose d’observer les ressaisies, la fréquence, la durée, le nombre de personnes, la complexité et l’impact d’une erreur. Ce dossier est rédigé par Erwan Kezzar de Contournement et Marc-Olivier Sercki de Pathta, deux acteurs privés du no-code et du développement : nous retenons la méthode d’observation, pas leurs gains ni leurs préférences d’outils comme règles générales.

Comparez ensuite les trois fiches. Un problème répété à faible conséquence n’appelle pas la même réponse qu’un événement rare mais capable d’arrêter les opérations. Une même organisation peut donc sécuriser une première situation, simplifier la deuxième et continuer d’observer la troisième. Les faits peuvent mener à des réponses différentes, sans poser un nouvel outil comme point de départ.

Suivez cet ordre pour ne pas transformer le diagnostic en argument commercial. Traitez d’abord la continuité, puis le travail inutile ; gardez la fonction sur mesure pour la fin. Arrêtez-vous dès qu’une réponse traite correctement les trois situations et leurs exceptions importantes.

Le Référentiel général d’écoconception des services numériques (RGESN) 2024 demande d’examiner la nécessité, les alternatives non numériques et les services existants. C’est ici un garde-fou de conception, pas une évaluation complète du RGESN, une preuve de rentabilité ni une obligation générale de renoncer à développer.

1. 1

   Sécuriser la continuité et les accès

   Quand l’examiner

   Une absence, une panne, un compte partagé, une perte de fichier ou une restauration incertaine menace le travail ou les données.

   Ce qu’il faut vérifier

   Corriger les droits, organiser les sauvegardes, tester régulièrement leur intégrité et leur restauration, puis écrire le fonctionnement dégradé et le retour à la normale.

   Point d’arrêt

   Ne transformez pas un incident de sécurité en prétexte pour ajouter des fonctions.

2. 2

   Supprimer ou simplifier le processus

   Quand l’examiner

   L’équipe alimente une étape, un fichier ou une validation dont personne ne sait plus expliquer l’utilité.

   Ce qu’il faut vérifier

   Retirer l’étape sur un périmètre limité, puis vérifier que le résultat et les contrôles utiles restent intacts.

   Point d’arrêt

   N’automatisez pas une habitude inutile : vous la rendriez seulement plus rapide et plus difficile à remettre en cause.

3. 3

   Configurer l’outil actuel et former

   Quand l’examiner

   Le logiciel en place sait peut-être faire le travail, mais la fonction, le paramétrage ou le mode opératoire n’a pas été essayé sur des cas réels.

   Ce qu’il faut vérifier

   Configurer un essai, documenter les exceptions et vérifier l’usage après une période représentative.

   Point d’arrêt

   Une démonstration commerciale réussie ne prouve pas que l’équipe maîtrise le travail un jour chargé.

4. 4

   Connecter ou automatiser de façon limitée

   Quand l’examiner

   Chaque outil remplit correctement son rôle, mais une donnée ou un statut est recopié de façon répétitive entre eux.

   Ce qu’il faut vérifier

   Tester un seul échange traçable, réversible et reprenable à la main, avec alerte en cas d’échec.

   Point d’arrêt

   Une automatisation sans alerte peut propager une erreur ou créer des doublons. Le contrôle doit rester visible.

5. 5

   Tester avant d’adopter un logiciel standard

   Quand l’examiner

   Le besoin est courant et une solution disponible paraît plausible ; elle doit couvrir les trois situations et leurs exceptions avant toute adoption.

   Ce qu’il faut vérifier

   Faire exécuter les trois situations et les principales exceptions pendant l’essai, vérifier l’export, les accès, le support et le coût au volume réel, puis ne l’adopter que si les résultats couvrent les cas importants.

   Point d’arrêt

   N’écartez pas le standard parce qu’il demande un changement d’habitude raisonnable ; n’acceptez pas non plus un contournement critique permanent.

6. 6

   Étudier une fonction sur mesure

   Quand l’examiner

   Le problème est répété, important et stable ; les réponses plus simples ont été raisonnablement testées ; un responsable métier peut décider et arrêter un pilote.

   Ce qu’il faut vérifier

   Définir la plus petite fonction qui produit un résultat vérifiable, son mode de reprise et les conditions de sortie.

   Point d’arrêt

   « Notre métier est unique » n’est pas une preuve. Les cas réels et l’échec documenté des options raisonnables le sont davantage.

Les signaux visibles sur le terrain ont souvent plusieurs causes. Un tableau n’est pas « trop gros » parce qu’il possède un nombre donné d’onglets ; il devient risqué lorsqu’il est critique, opaque, mal protégé ou impossible à reprendre. À l’inverse, un fichier simple peut rester un bon outil pendant des années.

Ces contre-cas ne ferment pas la décision pour toujours. Ils indiquent seulement ce qu’il faut vérifier en premier.

Les trois scénarios ci-dessous sont fictifs, pas des cas clients. Aucun résultat n’y est mesuré et aucun gain n’en est déduit. Ils servent à montrer comment choisir la prochaine question.

Dans ces trois cas, le secteur ne décide rien à lui seul. Ce sont les faits qui orientent la réponse.

Une matrice n’a pas besoin d’un score pour être utile. Pour chaque situation, écrivez les réponses ci-dessous et joignez la preuve disponible. Si une ligne décisive reste inconnue, elle devient une question de l’essai, pas une valeur par défaut.

Ne favorisez pas le sur-mesure au seul motif qu’il reproduit les habitudes actuelles. Vérifiez aussi l’entretien, la sécurité, la reprise, l’adoption et la sortie. Une partie de ces efforts peut être mutualisée par l’éditeur standard, sans supprimer les coûts internes ni la réversibilité à vérifier. De même, le standard n’est pas automatiquement meilleur : ses limites doivent être testées sur les exceptions qui comptent.

Ces critères ne tranchent pas seuls. Ils servent à construire un essai limité, avec une sortie claire si les faits contredisent l’orientation de départ.

Même avec une orientation claire, ne passez pas directement au déploiement. Pour les réponses 3 à 6, transformez l’hypothèse en essai : quelques utilisateurs représentatifs, un seul résultat métier, des cas normaux et des exceptions, une reprise manuelle et une date de décision.

La page DesignGouv recommande de partir des besoins et de tester avant de développer. Ces bonnes pratiques visent les services publics ; nous les utilisons seulement comme méthode de conception transférable. Le dossier pratique France Num, rédigé par deux prestataires privés, conseille lui aussi de commencer petit, cartographier les exceptions, tester et prévoir documentation, formation et maintenance.

Le coût total de possession, ou TCO, regroupe les dépenses et le temps interne nécessaires pour mettre en place, exploiter, faire évoluer puis quitter une solution sur une même période. Le calcul vient après le diagnostic : chiffrer trop tôt donne un chiffre précis à une réponse encore incertaine.

Laissez chaque poste inconnu « à confirmer ». Zéro signifie qu’un poste a été examiné et qu’il ne s’applique pas dans le scénario, pas qu’il a été oublié. Comparez aussi le statu quo : temps de reprise, erreurs, abonnements conservés et risque accepté.

Pour construire ensuite des scénarios de trésorerie et de capacité sans compter deux fois le temps, utilisez le guide Calculer le ROI d’une application métier. Si la réponse retenue est une connexion limitée, le guide Quel processus métier automatiser en premier ? aide à vérifier le premier candidat.

Reprenez vos trois fiches. Pour chacune, choisissez une réponse ou le verdict OBSERVER, puis écrivez pourquoi et ce qui permettra de confirmer ou d’abandonner cette orientation. La phrase doit pouvoir être comprise par la personne qui fait le travail et par celle qui paie.

Votre décision peut être très simple : restaurer une sauvegarde, supprimer une validation, former deux personnes, tester un connecteur, faire jouer trois dossiers dans un logiciel standard, cadrer une fonction sur mesure — ou observer encore. Vous n’avez pas forcément un projet à l’arrivée. Vous aurez surtout évité de financer une solution qui ne traite pas le problème observé.

Chacune de ces suites possibles a son dossier. Si le blocage est une tâche répétitive, commencez par choisir quel processus métier automatiser en premier. Si vous devez défendre un budget, le calcul du retour sur investissement sépare le gain de trésorerie du gain de capacité, sans les additionner à tort.

Si un outil existe déjà et atteint ses limites, la comparaison utile dépend de ce qui est en place : Airtable ou Notion face à une application métier, Power Apps face à une application sur mesure en environnement Microsoft, ou le remplacement d’une base Microsoft Access par une application web. Si la décision est prise, le cahier des charges fige ce qui doit être construit, et le guide sur le choix d’un prestataire sur preuves évite de confier ce travail sur une simple impression.