Choisissez le périmètre d’un premier logiciel métier : parcours utile, tâches manuelles acceptables, critères de lancement et décisions après le pilote.
La première liste de besoins mélange souvent les opérations indispensables et les améliorations attendues depuis des années. Elle contient un tableau de bord, des notifications, plusieurs exports et parfois une application mobile. Pour choisir ce qui entre dans la première version, partez du travail qu’un utilisateur doit pouvoir terminer.
Un MVP est une version utilisable qui permet de vérifier une hypothèse avec ses utilisateurs. Atlassian distingue ce premier produit d’une preuve de faisabilité technique. Pour un logiciel interne, l’hypothèse peut porter sur la réduction des ressaisies ou la possibilité de suivre un dossier sans demander son état à un collègue.
Choisir un problème observable
« Digitaliser l’entreprise » reste trop large pour délimiter une première livraison. Décrivez une situation avec son point de départ et son résultat attendu. Par exemple, dans un cas fictif, une demande d’intervention arrive par email, puis circule entre plusieurs personnes avant d’être affectée à un technicien.
L’entreprise souhaite que chaque demande reçoive un responsable et que le demandeur puisse consulter son état. Ce besoin permet d’observer si le pilote fonctionne. Le remplacement de tous les outils du service n’est pas nécessaire pour le vérifier.
Avant de fixer un objectif chiffré, mesurez le fonctionnement actuel sur des dossiers comparables. Notez aussi les erreurs et les relances. Un traitement plus rapide qui multiplie les affectations incorrectes n’améliore pas forcément le service rendu.
Dessiner un parcours complet
Écrivez les étapes du cas choisi depuis la création jusqu’à la clôture. Précisez qui agit et ce qui permet de passer à l’étape suivante. Une première version doit couvrir assez de ce parcours pour être utilisée dans les conditions prévues.
Dans notre exemple fictif, le périmètre comprend la saisie de la demande, son affectation, la mise à jour de son état et sa clôture. Si l’affectation dépend d’une information absente, ajoutez un moyen de demander cette information. Sinon les utilisateurs reprendront le suivi hors du logiciel dès le premier dossier incomplet.
Le parcours révèle également les dépendances. Un champ « client » exige une manière de retrouver ou créer le bon client. Une notification suppose un destinataire fiable et un traitement des échecs. Chiffrez ces besoins avec la fonctionnalité qui les utilise.
Conserver certaines tâches manuelles avec un responsable
Une opération peu fréquente peut rester manuelle pendant le pilote. L’équipe peut importer un référentiel contrôlé, préparer un rapport hebdomadaire ou valider une affectation proposée. Pour chaque tâche conservée, indiquez qui s’en charge et comment son exécution est vérifiée.
| Besoin de l’exemple fictif | Décision pour le pilote | Condition à vérifier |
|---|---|---|
| Affecter une demande | Dans le logiciel | Responsable visible et modification tracée |
| Choisir le technicien automatiquement | Reporter | Affectation manuelle praticable avec le volume prévu |
| Consulter le statut | Dans le logiciel | Accès limité aux personnes autorisées |
| Produire un bilan avancé | Travail manuel temporaire | Temps de préparation suivi chaque semaine |
| Traiter une demande incomplète | Dans le parcours | Retour vers le demandeur possible |
Les tâches manuelles ont un coût. Mesurez-le pendant le pilote et définissez à partir de quel volume elles deviennent impraticables. Une simplification utile au lancement peut nécessiter une automatisation lorsque davantage d’utilisateurs arrivent.
Préserver les conditions d’utilisation nécessaires
Le périmètre peut être réduit sans retirer les protections exigées par le fonctionnement retenu. Si deux clients utilisent le même portail, la séparation de leurs données appartient au premier périmètre. Si le logiciel devient le seul endroit où une opération est enregistrée, prévoyez la récupération des données et le traitement des incidents.
La qualité attendue dépend aussi du contexte. Un pilote accompagné avec quelques utilisateurs connus n’a pas les mêmes besoins d’assistance qu’un accès public. Définissez le groupe autorisé, les horaires d’accompagnement et les moyens de signaler un problème.
Inscrivez des critères d’acceptation vérifiables pour les cas normaux et les cas d’erreur qui empêcheraient le travail. Une panne du service d’email doit par exemple conduire à un état compréhensible si les notifications font partie du parcours.
Fixer les limites avant d’estimer
Ajoutez une liste des éléments reportés et des hypothèses de dimensionnement. Combien de personnes participeront au pilote ? Quels types de dossiers seront exclus ? Les données historiques seront-elles reprises ? Ces réponses influencent le coût même si le nombre d’écrans reste identique.
Lorsqu’un nouveau besoin apparaît, estimez son effet sur le parcours, le budget et le calendrier. La personne qui porte le produit décide de l’ajouter, de remplacer un autre élément ou de le reporter. Gardez la décision dans le cahier des charges pour que les utilisateurs et le prestataire travaillent avec le même périmètre.
Pour une PME marocaine qui prépare des échanges en français et en arabe, précisez les usages linguistiques du pilote. Afficher quelques libellés traduits ne suffit pas à valider la saisie, la recherche et les documents réellement utilisés par l’équipe.
Décider de la suite à partir des dossiers traités
Fixez une date de revue et les observations à recueillir : dossiers terminés, temps consacré aux reprises, demandes restées bloquées et charge des tâches manuelles. Interrogez les personnes qui ont utilisé le logiciel, y compris celles qui l’ont abandonné pour revenir à leur méthode précédente.
La suite peut être une extension du pilote, la correction d’un obstacle précis ou l’arrêt d’une fonction qui apporte peu. Demandez un exemple de dossier pour chaque difficulté signalée. Ces cas concrets permettent de choisir la prochaine amélioration et de vérifier ensuite si elle a résolu le problème.