Pour acheter un logiciel métier sur mesure, décrivez d'abord le travail à accomplir et les preuves qui permettront d'accepter le résultat. Un devis devient exploitable lorsque les règles, les données, les intégrations et la recette sont suffisamment précises pour que votre équipe et le prestataire parlent du même produit.
Ce guide s'adresse aux entreprises françaises qui préparent un outil interne, un portail client ou une application de gestion. TuniCyberLabs accompagne ces acheteurs à distance. La qualité de la collaboration repose sur des responsabilités explicites et des livrables vérifiables ; elle ne suppose pas une implantation locale.
Décrire une journée de travail réelle
Prenons un exemple fictif : une société de maintenance souhaite remplacer les fichiers utilisés pour planifier ses interventions. « Gérer les interventions » reste trop vague. Il faut savoir qui reçoit la demande, comment un technicien est choisi, quelles pièces sont nécessaires et qui valide le compte rendu.
Pendant le cadrage, suivez une demande de son arrivée jusqu'à sa clôture. Notez les décisions prises en dehors des outils actuels : appel téléphonique, validation orale, copie d'un fichier ou correction d'une adresse. Ces gestes révèlent souvent les règles qui manquent au cahier des charges.
Demandez aussi ce qui se passe lorsque le parcours normal échoue. Un client absent, une pièce indisponible ou une intervention partiellement réalisée doivent produire un état compréhensible. Le logiciel doit représenter ces situations avant que l'équipe puisse les tester.
Construire une fiche de cadrage courte et précise
Une première fiche peut tenir sur quelques pages si elle distingue les faits, les décisions et les inconnues. Elle sert à préparer l'estimation ; elle ne prétend pas détailler tous les écrans du futur produit.
- ▸Objectif : réduire les ressaisies entre la demande et la facturation.
- ▸Utilisateurs : accueil, planification, techniciens et responsable administratif.
- ▸Périmètre initial : demandes, affectations, comptes rendus et export validé.
- ▸Hors périmètre : optimisation automatique des tournées et gestion complète des stocks.
- ▸Dépendances : disponibilité de l'interface comptable et qualité du fichier clients.
- ▸Décideurs : un responsable métier pour les règles et un responsable technique pour les accès.
Pour chaque inconnue, indiquez comment elle sera levée. Une documentation d'interface manquante peut nécessiter une investigation. Une règle d'approbation contestée nécessite une décision métier. Les traiter comme deux problèmes différents évite de demander au développement de résoudre un arbitrage organisationnel.
Écrire la recette avant de valider le devis
La recette vérifie que le produit satisfait des conditions convenues. « L'écran fonctionne » n'est pas une condition assez précise. Utilisez une fiche qui relie un scénario, un jeu de données, un résultat attendu et une personne habilitée à accepter.
Voici une fiche illustrative pour l'affectation d'une intervention :
- ▸Situation : une demande validée concerne un site actif et une compétence identifiée.
- ▸Action : le planificateur affecte un technicien disponible.
- ▸Résultat attendu : l'intervention apparaît dans son planning et conserve son identifiant.
- ▸Cas refusé : un utilisateur sans droit de planification ne peut pas modifier l'affectation.
- ▸Cas particulier : une nouvelle affectation conserve l'historique de la précédente.
- ▸Preuve : scénario rejoué sur l'environnement de recette avec les données convenues.
- ▸Validation : le responsable de planification accepte ou décrit l'écart observé.
Ajoutez les critères propres à votre activité : formats, pièces jointes, recherche, accessibilité attendue ou fonctionnement mobile. Définissez les conditions de mesure d'une exigence de rapidité. Un temps de réponse sans volume de données, réseau et charge de référence ne constitue pas un engagement suffisamment testable.
Séparer anomalie, évolution et découverte
Une anomalie correspond à un écart avec un résultat convenu. Une évolution modifie ce résultat ou ajoute un besoin. Une découverte révèle une information qui manquait, par exemple une limitation de l'outil comptable. Prévoir ces trois catégories rend les discussions plus précises.
Conservez un journal des décisions avec l'auteur, la date et les conséquences sur le périmètre. Lorsqu'une évolution est acceptée, mettez à jour les critères de recette et l'estimation associée. Une discussion en réunion ne doit pas créer un engagement invisible pour les personnes absentes.
Prévoyez également le traitement des écarts non bloquants. Qui décide qu'une version peut être utilisée ? Quelles limitations sont communiquées ? À quel moment les corrections sont-elles réexaminées ? Ces réponses doivent exister avant la pression de la mise en service.
Inclure les droits et les données dans les essais
Un parcours réussi avec un compte administrateur ne prouve pas que les autorisations sont correctes. Faites tester les opérations avec chaque rôle utile et incluez les actions qui doivent être refusées.
Le référentiel OWASP ASVS propose des exigences de vérification de sécurité pour les applications. Il peut aider à choisir des contrôles adaptés au projet, à condition de préciser leur version, leur périmètre et les preuves attendues. La simple référence à un standard ne remplace pas les essais.
Pour une reprise de données, demandez un essai avant la bascule : rapprochement des volumes, contrôle de dossiers représentatifs et liste des enregistrements rejetés. Le métier doit pouvoir expliquer les différences. Un import techniquement terminé peut encore contenir des associations incorrectes.
Acheter aussi la capacité à reprendre le produit
Le transfert comprend les accès convenus, le code, les instructions de déploiement, les dépendances et les procédures utiles à l'exploitation. Identifiez le destinataire de chaque livrable. Un document que personne ne sait utiliser n'est pas un transfert réussi.
Organisez une répétition : un membre de l'équipe cliente suit la procédure pour créer un compte, publier une version de test et retrouver la cause d'un traitement en échec. Les questions soulevées deviennent des améliorations de la documentation.
Demandez aussi ce qui reste à la charge du prestataire après la livraison et comment une intervention sera commandée. Le support, les évolutions et les services externes doivent avoir un périmètre lisible.
Comparer des propositions réellement comparables
Soumettez la même fiche de cadrage et les mêmes scénarios aux prestataires. Demandez une réponse qui distingue ce qui est inclus, exclu, conditionnel ou à investiguer. Le guide de comparaison des prestataires, disponible en anglais, propose une grille d'évaluation complémentaire. Pour un remplacement progressif, notre article sur la modernisation par étapes apporte un autre angle technique.
Découvrez nos services d'ingénierie logicielle, puis présentez votre processus métier. Un exemple de dossier, une liste des outils concernés et vos contraintes de reprise permettent de commencer par un cadrage concret.