Le problème semble clair : le logiciel ralentit l’équipe et doit être refait. Au premier atelier, chacun décrit pourtant une autre application. Le support veut moins d’incidents, les métiers veulent conserver leurs raccourcis et la DSI veut supprimer une dépendance dont personne ne maîtrise plus les accès.
Un cahier des charges de refonte doit relier ces attentes à des décisions vérifiables. Il décrit ce qui doit continuer à fonctionner, ce qui doit changer, les données à reprendre, les systèmes à connecter et les conditions d’exploitation. Une liste d’écrans ou un choix de framework ne remplit pas ce rôle.
En pratique, le dossier doit permettre de décider ce qui sera reçu et ce qui reste à vérifier. Il peut évoluer pendant le projet, à condition de distinguer les décisions prises, les hypothèses à tester et les demandes encore ouvertes. Sans cette distinction, incidents et reprises manuelles reviennent dans les ateliers et chaque arbitrage oblige à reconstruire le périmètre.
Dawap utilise le cadrage d’une refonte de logiciel métier pour rapprocher usages, code, données et contraintes du SI. Le modèle ci-dessous aide vos équipes à préparer les informations utiles et à comparer les propositions sur des livrables explicites.
Pour qui : un métier porteur du besoin et une DSI responsable du SI
Ce modèle s’adresse à une organisation qui remplace ou modernise un logiciel existant. Il convient lorsque des règles ont une valeur particulière, que plusieurs applications échangent des données ou que la continuité des opérations impose une trajectoire de reprise. Il ne suppose pas que toute la solution doit être reconstruite.
Identifiez un responsable métier capable d’arbitrer les usages, un interlocuteur technique pour le SI et une personne qui pilote l’ensemble. Des utilisateurs représentatifs, le support et l’exploitant doivent pouvoir contribuer. La disponibilité de ces acteurs constitue une dépendance de planning au même titre qu’un accès à une API.
Lorsque le besoin peut être couvert par un outil standard, gardez cette option dans l’étude. Le sur-mesure prend son sens sur les fonctionnalités et intégrations qui répondent réellement à vos particularités. Le cahier des charges doit permettre cet arbitrage, sans imposer une reconstruction par principe.
Le modèle de cahier des charges à compléter
Télécharger le modèle de cahier des charges en texte modifiable. Les rubriques demandent des informations précises, mais elles peuvent rester courtes lorsque le périmètre est simple. Une inconnue est à marquer comme telle avec la personne chargée de la lever.
| Rubrique | Information à renseigner | Décision permise |
|---|---|---|
| Activité et problème | Opération concernée, irritant observé, conséquence et utilisateurs. | Dire pourquoi le chantier est prioritaire. |
| Existant | Code, rôles, règles, données, flux, incidents et accès disponibles. | Déterminer ce qu’il faut auditer ou conserver. |
| Périmètre cible | Fonctions nécessaires, exclusions et premier lot utile. | Éviter un remplacement indéfini de tout le SI. |
| Règles métier | Conditions, exceptions, décisions et exemples de refus. | Écrire une recette qui protège le fonctionnement utile. |
| Données et interfaces | Sources, propriétaires, volumes connus, qualité et contrats d’échange. | Préparer migration et intégration. |
| Qualité et sécurité | Parcours critiques, droits, tests, revues et contrôles attendus. | Définir des preuves de livraison adaptées. |
| Exploitation | Hébergement, support, supervision, sauvegarde et restauration. | Nommer le destinataire et les responsables. |
| Pilotage | Décideurs, jalons, dépendances, arbitrages et changement de périmètre. | Rendre le projet gouvernable. |
| Réception et transfert | Signatures, réserves, bascule, documentation, code et accès. | Savoir quand un lot est effectivement reçu. |
Recueillir les besoins dans des situations de travail réelles
Demander le dernier cas difficile plutôt qu’une fonction souhaitée
Une demande comme « un écran plus simple » doit être rapprochée d’une opération précise. Quel dossier l’utilisateur traitait-il ? Quelles informations lui manquaient ? Quelle décision a demandé un appel ou un fichier parallèle ? Le récit d’un cas récent révèle souvent une exception absente de la liste initiale.
Complétez l’observation avec le résultat attendu : opération terminée, document produit, contrôle effectué ou refus justifié. Les problèmes de performance, les doubles saisies et les contournements manuels doivent être reliés à une conséquence métier observable, sans leur attribuer une économie chiffrée qui n’a pas été mesurée.
Conserver la trace des règles implicites
Le premier signal discret est un fichier partagé que plusieurs personnes utilisent sans le considérer comme une partie du logiciel. Le second est un traitement réservé à une seule personne, parce qu’elle connaît l’ordre des opérations ou les corrections à appliquer. Ces pratiques peuvent porter des règles que la refonte doit reprendre, simplifier ou supprimer après décision.
Le dossier conserve la provenance de la règle et son arbitre. Deux utilisateurs peuvent décrire des comportements différents parce qu’ils interviennent sur des populations ou des moments distincts. Le cadrage doit résoudre cette différence avant de l’inscrire comme une seule fonctionnalité.
Auditer pour choisir ce qui sera conservé, connecté ou remplacé
Demandez un inventaire du code et de ses dépendances, mais aussi des accès, traitements planifiés, incidents et données. Le document doit signaler ce qui a été réellement examiné. Un audit sans accès à une application connectée ne peut pas en certifier les comportements.
La trajectoire peut varier par domaine : stabiliser une partie viable, conserver un service, exposer une interface ou reconstruire une fonction. La matrice de choix pour moderniser un legacy aide à comparer ces options sans décider globalement de tout réécrire.
Inscrivez les hypothèses qui changent le budget ou la trajectoire. Si une interface ERP reste à vérifier, nommez la preuve attendue et la date à laquelle elle doit être disponible. Une réserve explicite permet d’ajuster le projet ; une hypothèse oubliée finit souvent par ressembler à une demande nouvelle.
Décrire les fonctionnalités par décision, exception et preuve
Pour chaque fonction, précisez l’acteur, l’objet manipulé, les préconditions, les règles, les refus et les effets sur les systèmes voisins. Ajoutez la manière de vérifier le résultat et la personne habilitée à l’accepter. Le niveau de détail doit permettre une discussion avec les métiers, pas seulement une estimation technique.
Exemple fictif : un commercial prépare une commande pour un compte professionnel. Le cahier des charges distingue tarif autorisé, disponibilité, reliquat, validation et création dans l’ERP. Il décrit aussi ce qui doit être refusé si le compte n’a pas le droit de commander. Le dessin du panier ne suffit pas à définir cette fonction.
L’ergonomie fait partie du périmètre : recherche, clavier, messages d’erreur, reprise d’une saisie et compréhension des statuts. Demandez une validation avec les utilisateurs concernés, sur les opérations fréquentes et les cas difficiles. Une nouvelle interface doit servir leur travail, pas seulement remplacer son apparence.
Exemple fictif rempli : remplacer un outil de devis professionnel
Le problème, le premier lot et les exclusions
Une équipe ADV prépare des devis dans un outil ancien. Le tarif du compte est lu dans un ERP, mais les corrections sont parfois conservées dans un tableur. Le premier besoin consiste à préparer un devis explicable et à conserver la décision commerciale. L’ERP reste responsable des comptes et des tarifs de référence ; son remplacement est exclu du chantier.
Le premier lot ouvre la consultation d’un compte autorisé, la composition du devis et sa validation interne. L’envoi automatique d’une commande et la reprise de tout l’historique restent hors de ce lot. Cette limite permet de recevoir les règles et les accès avant d’ajouter un effet dans le système de gestion. L’exemple est entièrement fictif et ne décrit pas un projet client.
| Fonction | Règle et exception | Preuve de réception |
|---|---|---|
| REQ-01 · Choisir le compte | Le contact accède seulement aux comptes qui lui sont autorisés. | Un compte autorisé est accessible ; un autre est refusé. |
| REQ-02 · Préparer le devis | Le prix de référence est retrouvé ; une exception commerciale exige le rôle prévu. | Le montant et la décision sont explicables, y compris après modification. |
| REQ-03 · Soumettre à validation | Le validateur retrouve la version examinée et les motifs de réserve. | Une modification pertinente après validation déclenche le traitement convenu. |
| REQ-04 · Consulter le dossier | Le devis et ses documents restent rattachés au compte et à leur contexte. | L’utilisateur retrouve la bonne version avec ses droits réels. |
Les inconnues qui changent la proposition
Le contrat de lecture des tarifs ERP n’est pas encore confirmé. Le dossier indique l’interlocuteur, les champs nécessaires et la preuve à obtenir depuis l’environnement de recette. Si l’interface ne donne pas les exceptions attendues, alors le périmètre est réexaminé avant de financer leur reproduction dans un second système.
La qualité des anciens devis reste également à qualifier. En revanche, le premier lot peut se limiter à des dossiers nouvellement créés si le métier accepte cette frontière et dispose encore de la consultation historique. Le document doit alors décrire le parcours entre ancien et nouveau logiciel, ses droits et la condition qui permettra de retirer l’ancien outil.
La recette, l’ergonomie et l’exploitation
La recette comprend le parcours courant et les refus : compte interdit, droit de remise absent, tarif indisponible et version de devis devenue différente. L’utilisateur doit comprendre si son travail est conservé, s’il peut réessayer et qui doit intervenir. La navigation au clavier, les messages et la reprise de saisie sont testés avec les personnes qui préparent réellement les dossiers.
L’exploitation précise la version, les traitements, les journaux et les accès nécessaires au support. Le premier lot doit pouvoir être installé et restauré sur la cible convenue. Une fonction qui paraît terminée sur le poste du développeur reste en réserve si le destinataire ne peut pas l’exécuter dans les conditions du SI prévues au cadrage.
Décider ce qui peut être ouvert après la démonstration
Exemple de décision sur REQ-01 : le compte autorisé est accessible, mais le test de refus échoue. Le lot n’est pas reçu pour cette population ; le décideur métier ne peut pas compenser le défaut de droits par un accord verbal. En revanche, une amélioration secondaire de présentation peut être différée si les règles, les accès et l’exploitation du périmètre ouvert sont reçus.
Le procès-verbal relie les entrées — version, jeu autorisé et critères — aux sorties : résultat, réserves et décision. Il nomme les responsabilités de correction, les dépendances, la preuve à rejouer et la date d’examen. Le scénario de repli et la journalisation sont conservés avec ce dossier pour que l’équipe destinataire puisse comprendre l’état accepté.
Décrire la reprise des données et les contrats d’interface
Fixer le périmètre historique et les règles de rapprochement
Listez les données utiles, leurs sources et leurs propriétaires. Distinguez ce qui doit être migré, archivé, nettoyé ou laissé dans l’ancien système. La conservation de tout l’historique peut être nécessaire dans certains cas ; elle doit être justifiée plutôt que devenir une règle automatique.
Le cahier des charges précise les contrôles de reprise : relations, pièces jointes, références et opérations reconstituées. La recette métier d’une migration donne une méthode pour accepter les données sur des preuves, au-delà du nombre d’enregistrements déplacés.
Qualifier les échanges au-delà du nom des logiciels
Écrire « connexion ERP » ne définit pas une intégration. Précisez les objets, le sens de l’échange, sa fréquence, l’authentification, les erreurs et les reprises attendues. L’API disponible, une passerelle partenaire ou un échange de fichiers ne proposent pas les mêmes conditions ; elles doivent être vérifiées avec les propriétaires des systèmes.
Une conception API-first prévoit les contrats nécessaires aux usages du logiciel et aux échanges. Elle n’impose pas une API publique ni l’exposition de toutes les données. Les droits et le périmètre de chaque consommateur doivent faire partie des critères d’acceptation.
Rendre la qualité de code et les livrables contrôlables
La qualité attendue doit se traduire en pratiques et en preuves proportionnées : revues de code, tests des règles critiques, contrôle des dépendances, construction reproductible et traçabilité des versions. Une couverture de tests annoncée sans lien avec les parcours ne suffit pas à qualifier le logiciel.
Définissez ce qui est remis à chaque lot : fonctionnalité démontrable, version identifiée, résultats des contrôles, documentation utile et réserves connues. La CI/CD peut automatiser les vérifications et le déploiement convenus. Le projet doit aussi préciser qui autorise la mise en production et comment sont traitées les migrations incompatibles.
Les contrôles de sécurité couvrent notamment les accès, les données et les interfaces réellement utilisés. Les exigences retenues peuvent être rapprochées d’OWASP ASVS, puis reliées à des vérifications adaptées. Citer un référentiel ne constitue ni une certification ni la preuve que tous ses contrôles ont été exécutés.
Prévoir planning, itérations et arbitrages sans figer toutes les réponses
Le planning doit distinguer jalons, dépendances et hypothèses. L’ordre des lots tient compte de la valeur métier, des interfaces disponibles et de la possibilité de faire cohabiter ancien et nouveau logiciel. Une date de lancement n’a pas la même solidité selon que ces prérequis sont reçus ou encore supposés.
Précisez les participants aux démonstrations, le délai d’examen des réserves et le décideur en cas de conflit. L’agilité permet d’ajuster les priorités ; elle ne dispense pas de suivre l’impact d’un changement sur le budget, la réception et les autres équipes.
Le partage des rôles entre DSI, métier, produit et prestataire évite qu’une demande validée localement engage tout le projet sans arbitrage. Le compte rendu doit conserver la décision et ses conséquences, pas seulement la liste des sujets discutés.
Faire entrer une nouvelle demande sans effacer l’accord précédent
Une demande nouvelle indique l’opération concernée, la raison du changement et les critères à ajouter. L’équipe décrit les effets sur les données, les interfaces, les tests et les livrables. Le décideur compare ensuite maintien du lot, déplacement d’une fonction ou modification du budget et du planning. L’arbitrage doit rester visible pour les personnes qui réceptionneront le résultat.
En réalité, figer toutes les fonctionnalités très tôt peut donner une illusion de maîtrise si les règles les plus risquées restent inconnues. Un dossier évolutif mais traçable permet de lever ces inconnues dans un ordre choisi. Il faut conserver les engagements déjà pris et distinguer une précision attendue d’un besoin effectivement nouveau.
Matrice de décision : comparer les propositions sur le même périmètre
Deux propositions peuvent employer les mêmes mots tout en couvrant des travaux différents. Dans cet exemple fictif, la première prévoit les écrans du devis, la seconde inclut aussi l’audit des tarifs, les droits, la recette et la reprise des documents. Leur comparaison commence par ces écarts, avant le montant ou la technologie annoncée.
| Point à rapprocher | Question à poser | Pièce attendue |
|---|---|---|
| Audit et inconnues | Qu’est-ce qui sera examiné avant de confirmer la trajectoire ? | Périmètre d’audit, accès nécessaires et livrables. |
| Données et échanges | Qui vérifie la qualité et les interfaces, et qui traite les écarts ? | Hypothèses, responsabilités et critères de reprise. |
| Qualité et recette | Qu’est-ce qui permet de refuser un lot et de le faire corriger ? | Contrôles, version reçue et gestion des réserves. |
| Exploitation et sortie | Qui peut déployer, diagnostiquer, restaurer et transmettre ? | Dossier d’exploitation et modalités de maintenance/réversibilité. |
La priorité est de rendre comparables les entrées et les sorties de chaque prestation. Les dépendances et responsabilités non couvertes restent nommées, avec leur coût à qualifier. Le coût complet comprend aussi la disponibilité du métier, la coordination des partenaires et la charge de support pendant la transition. Aucun prix public standard ne permet de remplacer cet examen.
À refuser : une estimation qui présente une interface non vérifiée comme déjà reçue. À différer : une fonction secondaire dont la valeur n’est pas encore arbitrée. À préparer immédiatement : les contrôles qui peuvent invalider le premier lot. Cette hiérarchie évite de financer une démonstration convaincante dont les conditions de mise en service restent inconnues.
Conserver la chaîne entre demande, livraison et acceptation
Une règle du cahier des charges doit pouvoir être retrouvée dans le lot livré et son dossier de recette. L’identifiant fonctionnel peut relier décision métier, version, test et réserve. Le but est de savoir ce qui a changé et ce qui a été accepté, sans imposer un outil particulier ou un document interminable.
Dans l’exemple du devis, REQ-03 doit retrouver la validation sur une version précise. Si le calcul ou le document évolue, alors l’équipe sait quels contrôles rejouer et qui peut accepter le résultat. La journalisation et la traçabilité techniques soutiennent cette preuve ; elles ne se substituent pas à la décision du métier sur la règle.
La procédure de repli complète le dossier lorsque la bascule peut modifier des données ou déclencher des effets externes. Elle décrit les limites du retour, les dépendances et l’autorité qui décide d’un arrêt. La supervision doit permettre de détecter les symptômes retenus assez tôt pour appliquer cette décision.
Intégrer hébergement, sauvegardes et transmission dans le périmètre
Le dossier indique qui héberge et qui exploite chaque composant. Il décrit les environnements de sandbox, recette et production, les accès nécessaires, la supervision, la gestion des incidents et la maintenance. Le code livré doit correspondre à un logiciel que son destinataire peut réellement recevoir.
Le guide hébergement cloud, serveur ou on-premise après refonte aide à comparer les options. La checklist de déploiement dans le SI précise les conditions de réception sur la cible choisie.
Inscrivez également les sauvegardes, la restauration testée, la documentation, la remise des accès et la réversibilité. Un coût d’exploitation ou de transfert oublié dans le périmètre peut réapparaître après la livraison, lorsque les choix sont plus difficiles à modifier. Le dispositif d’hypercare et de transfert au support doit également prévoir les disponibilités et les critères de sortie de la stabilisation.
Erreurs fréquentes dans un cahier des charges de refonte
- Décrire uniquement des écrans. Les règles implicites, tâches planifiées et intégrations peuvent porter l’essentiel du fonctionnement à conserver.
- Demander une copie exacte et une transformation complète. Les différences attendues et leurs arbitres doivent être identifiés pour éviter une recette contradictoire.
- Faire estimer des interfaces non vérifiées sans réserve. La disponibilité, le contrat technique et les accès influencent directement l’effort.
- Reporter l’exploitation à la fin. L’hébergement, les droits et la restauration modifient le périmètre de livraison.
- Choisir seulement le montant de réalisation. Maintenance, coordination, reprise des données et contraintes d’exploitation participent au coût complet.
Le coût de reprise d’un logiciel métier existant doit être lu avec ces inconnues et ces charges. Un chiffrage utile rend ses hypothèses visibles ; il ne remplace pas leur validation.
Plan d’action : transformer le modèle en dossier de consultation
- Réunir les métiers, la DSI et l’exploitant autour de quelques opérations représentatives.
- Compléter les rubriques avec les faits disponibles et identifier les inconnues sans les masquer.
- Faire auditer les points qui changent la trajectoire, le coût ou la capacité de reprise.
- Définir un premier lot avec ses fonctionnalités, ses données et ses critères de réception.
- Demander une proposition qui distingue livrables, hypothèses, exclusions et dépendances.
- Prévoir le traitement des évolutions, les jalons de décision et le passage en exploitation.
La consultation devient comparable lorsque les prestataires répondent au même besoin et expliquent leurs différences de périmètre. Un point non couvert reste une question à arbitrer ; il ne doit pas disparaître parce qu’une proposition commerciale paraît plus simple.
Conclusion : cadrer les décisions qui rendront la refonte recevable
Le cahier des charges relie le problème métier au logiciel à recevoir. Il conserve les règles utiles, précise les interfaces et prépare les preuves de fonctionnement, avec les personnes capables de décider.
Sa valeur vient aussi de ses limites explicites : ce qui est exclu, ce qui reste inconnu et ce qui pourra évoluer. Cette visibilité permet de piloter des itérations sans perdre la maîtrise de l’engagement initial.
Le modèle téléchargeable fournit une base de travail. Les exemples doivent être remplacés par vos opérations réelles, vos contraintes et vos critères d’acceptation, avec les documents et accès autorisés nécessaires à l’audit.
Dawap peut vous accompagner pour auditer et cadrer la refonte de votre logiciel sur mesure, puis transformer les décisions prises avec vos équipes en lots testables, intégrés à votre SI et prêts à être exploités.
