Les cahiers des charges du développement sous contrat doivent-ils rester sous Excel ? — Bien choisir le format des livrables

« Nous avons reçu une version révisée du cahier des charges, mais sans savoir ce qui avait réellement changé, et nous l’avons quand même tamponnée comme acceptée. »

« Au moment de commander une modification, le cahier des charges Excel qui nous avait été livré s’est révélé complètement différent des écrans actuels. »

« La société de développement nous a envoyé un cahier des charges rédigé en style Excel « papier quadrillé » — est-ce vraiment normal ? »

Lorsqu’on externalise le développement d’un système, le cahier des charges et les documents de conception sont livrés en même temps que le programme. Dans le développement sous contrat au Japon, ces documents sont extrêmement souvent construits sous Excel, fréquemment rédigés dans ce que l’on appelle le « papier quadrillé Excel » — un style qui découpe les cellules en petits carrés et traite la feuille comme du papier à lettres.

Les critiques du papier quadrillé Excel ne manquent pas sur Internet, mais la plupart portent sur son caractère peu pratique en tant que document interne au sein d’une équipe de développement. Cet article adopte un angle différent : il se concentre spécifiquement sur le cahier des charges livré au client dans le cadre d’un développement sous contrat, et détaille ce qui ne va pas et quel format choisir, avec le vocabulaire pratique de la gestion contractuelle : recette, changements de spécifications et maintenance. L’objectif est de proposer un contenu utile aussi bien au client qui commande le développement qu’à la société qui le livre.

1. La conclusion d’abord

Commençons par les points essentiels.

• Le format du cahier des charges livré ne doit pas être choisi en fonction de « est-ce facile à écrire pendant le développement », mais en fonction de « le client peut-il le relire », « peut-il résister à la recette », « les différences liées à un changement de spécifications peuvent-elles être partagées » et « sera-t-il encore utilisable en maintenance dans plusieurs années ».
• La conclusion n’est pas « abandonner Excel », mais « abandonner le papier quadrillé et remettre chaque format à sa juste place » : le texte dans Word, les tableaux dans de véritables tableaux Excel, les schémas dans un outil de dessin, et la trace d’un accord dans un PDF.
• Avant de débattre du format, il faut fixer dans le contrat lui-même (l’identification des livrables dans le contrat individuel) quels documents comptent comme livrables et si l’on recevra un original modifiable.

Le tableau suivant résume le format recommandé selon la nature du document.

Voyons maintenant pourquoi, point par point.

2. Ce qui pose problème dans un cahier des charges Excel « papier quadrillé » en tant que livrable

Précisons d’emblée : le logiciel Excel n’est pas le coupable. En tant qu’outil de calcul et de tableaux, Excel est excellent, et comme on le verra plus loin, c’est même le bon choix pour des documents comme les fiches de définition des champs. Le problème est de compresser du texte, des schémas et des tableaux — des éléments de nature fondamentalement différente — tous ensemble dans du « papier quadrillé ».

Pour un document interne à l’entreprise, ce n’est qu’un problème qui gêne ceux qui l’ont rédigé. Mais dès qu’il s’agit d’un livrable, la donne change, car un cahier des charges est un livrable que le client paie, il fait l’objet d’une recette, et c’est un actif utilisé pendant des années. Vu sous l’angle du livrable, le papier quadrillé Excel pose les problèmes suivants.

2.1 Impossible à relire intégralement lors de la recette

Le papier quadrillé Excel ne dispose d’aucun mécanisme de suivi des différences aussi pratique que le suivi des modifications de Word. Pour être précis, l’environnement de coédition de Microsoft 365 dispose bien d’un historique des modifications de cellules (« Afficher les modifications » ou l’historique des versions), et des outils comme Spreadsheet Compare existent pour comparer des classeurs entre eux. Mais ce qu’ils peuvent suivre concerne surtout les valeurs de cellules et les formules ; ils ne couvrent pas le texte contenu dans les formes et zones de texte que les documents en papier quadrillé utilisent abondamment, et dans un flux de livraison construit autour d’allers-retours de fichiers par e-mail, l’historique de coédition ne fonctionne de toute façon pas du tout.

Au final, lorsque le client reçoit une version révisée censée refléter ses remarques de relecture, il doit chercher à l’œil nu « ce qui a réellement changé ». Relire intégralement des dizaines de feuilles à chaque fois n’étant pas réaliste, en pratique le tampon de recette est apposé sur la base d’un « c’est probablement corrigé ».

C’est une recette purement formelle. La recette est la procédure consistant à « vérifier qu’un livrable correspond au contenu convenu et à l’accepter » ; dès que cette étape devient creuse, un problème découvert plus tard dégénère en discussion stérile — « vous avez pourtant validé la recette » contre « non, ce n’était pas livré sous une forme permettant de vérifier ».

2.2 Aucune trace d’accord ne survit à un changement de spécifications

Les spécifications changent forcément en cours de développement. Lorsque le document est un papier quadrillé Excel, les échanges autour de ces changements ont tendance à se transformer en « pile de copies de fichiers ». Beaucoup reconnaîtront un nom de fichier du type cahier_des_charges_v2_final_corrige(2).xlsx.

Le problème est qu’il devient impossible de déterminer a posteriori quelle version « les deux parties ont réellement acceptée ». Lorsqu’un désaccord surgit sur un coût supplémentaire ou un délai, c’est le document convenu qui sert de base pour le trancher. Si l’on ne sait plus lequel c’est, la discussion tourne au dialogue de sourds.

2.3 Un écart se creuse avec l’implémentation en phase de maintenance

Comme un document en papier quadrillé coûte cher à mettre à jour, il cesse peu à peu d’être actualisé au fil des modifications réalisées après la livraison. Personne n’ose y toucher de peur de casser la mise en page, le texte contenu dans les formes n’apparaît pas dans la recherche donc les corrections manquantes s’accumulent — et quelques années plus tard, on se retrouve avec « un cahier des charges qui existe, mais dont plus personne ne sait s’il correspond encore à la réalité ».

La facture de cette situation arrive à la prochaine modification. Si le document n’est plus fiable, il faut repartir de zéro en enquêtant sur le système réel (l’application en fonctionnement et le code source), et cette charge de travail vient s’ajouter au devis. Laisser un document sans maintenance se traduit plus tard par des coûts de modification plus élevés.

2.4 Le client ne peut pas vraiment l’exploiter

Une mise en page pensée pour l’impression est difficile à lire à l’écran. De plus, comme le contenu est dispersé sur de nombreuses feuilles et formes, la recherche en texte intégral fonctionne mal, et retrouver « où était écrite telle spécification » prend du temps. Le client a également du mal à le réutiliser — ajouter des notes d’exploitation, le reprendre dans un support de présentation interne — de sorte qu’un document pourtant payé finit souvent par « simplement rester rangé ».

3. L’angle contractuel — un cahier des charges est un « livrable »

Avant d’aborder la question du format, prenons un peu de hauteur. Un cahier des charges ou un document de conception ne devient un livrable contractuel, au même titre que le programme lui-même, qu’à partir du moment où il est défini comme tel dans le contrat. Autrement dit, un document non spécifié dans le contrat n’est pas nécessairement quelque chose que l’on est en droit de recevoir. Le modèle de transactions et de contrats pour les systèmes d’information de l’IPA est lui aussi structuré autour de l’identification des livrables dans le contrat individuel et de la définition de la méthode et du délai de recette. La structure d’ensemble de ce modèle de contrat est expliquée dans un article séparé, Comment structurer un contrat de développement sous contrat et d’exploitation-maintenance — choisir entre mandat quasi et contrat d’entreprise à la lumière du « modèle de transactions et de contrats » de l’IPA.

Autrement dit, le débat entre Excel et Word n’a de sens qu’une fois les bases suivantes établies.

• Quels documents sont des livrables : les lister au niveau du nom de chaque document, et non sous la forme vague d’un « ensemble de documentation ».
• Sous quel format ils sont reçus : cela inclut-il un original modifiable (fichier Word ou Excel) ? Un livrable en PDF seul pose problème en maintenance.
• La méthode de recette : que faut-il vérifier avant d’accepter le livrable ? Comment les différences d’une version révisée sont-elles présentées ?
• Le traitement des droits d’auteur et de la réutilisation : le client peut-il copier ou modifier le document en interne ? Le document pourra-t-il être transmis si la maintenance est un jour confiée à une autre société ?

Si ce point n’est pas réglé dans le contrat, quel que soit le format choisi, aussi soigné soit-il, on finira par se disputer pour savoir si ce document faisait même partie du périmètre de livraison. Pour la mise au point à effectuer avant de passer commande, voir aussi Ce qu’il faut clarifier avant de commander le développement externalisé d’une application Windows.

4. Les options de format de livraison — comparées sous l’angle de « est-ce que cela fonctionne comme livrable »

Une fois les bases établies, il reste à choisir le format. Comme indiqué en introduction, les axes d’évaluation sont au nombre de quatre : la lisibilité pour le client, la facilité de relecture et de recette, la gestion des différences lors d’un changement de spécifications, et la pérennité en phase de maintenance.

Quelques précisions sur chacun.

4.1 Word — le premier choix pour un cahier des charges essentiellement rédactionnel

Un document qui « parle en texte » — un document de conception générale, la description d’un flux métier — trouve naturellement sa place dans un traitement de texte. Word intègre d’emblée tous les outils dont un document livrable a besoin.

• Styles de titre et table des matières automatique : la structure du document devient claire, et l’on peut sauter directement de la table des matières à la section voulue.
• Suivi des modifications (fonction de révision) : ce qui a changé dans une version révisée apparaît en rouge, directement dans le document. Cela change radicalement l’efficacité réelle de la relecture et de la recette.
• Commentaires : les remarques du client et les réponses qui leur sont apportées restent attachées au document lui-même.
• Comparaison de documents : on peut afficher, même après coup, la différence entre deux versions.

Le client n’a besoin d’aucun outil particulier ni d’apprentissage, et le document passe tel quel comme format de livraison — un avantage pratique non négligeable.

Le piège à éviter est le suivant : construire un document qui n’a l’air soigné qu’en apparence, sans jamais utiliser les vrais styles, retombe dans le même travers — on pourrait presque parler de « papier quadrillé Word ». Les titres doivent utiliser les styles de titre, et la mise en page doit passer par la mise en forme plutôt que par des espaces répétés. Par ailleurs, le problème de « quelle est la dernière version » peut aussi survenir avec Word, d’où l’intérêt de l’associer à la gestion des versions décrite plus loin.

4.2 Ramener Excel à un « véritable tableau »

Des documents comme une fiche de définition des champs d’écran, une liste de codes ou une matrice de droits sont, par nature, des tableaux. Les rédiger sous Word serait au contraire peu pratique — Excel est le bon choix. Mais il faut l’utiliser comme un véritable tableau exploitable en tant que données, et non comme du papier quadrillé.

• Une ligne par enregistrement, une colonne par attribut. Une seule table par feuille.
• Ne pas construire la mise en page avec des fusions de cellules. Les en-têtes occupent une seule ligne, en haut.
• Ne pas casser la structure des données pour le rendu à l’impression (traiter la présentation d’impression par un autre moyen).

Construit de cette façon, le document peut être traité mécaniquement en phase de maintenance. Des réutilisations comme le rapprochement entre la définition des champs et la définition réelle de la base de données, ou l’utilisation directe de la liste comme base de cas de test, deviennent possibles, ce qui facilite d’autant la vérification que « le document ne s’est pas écarté de l’implémentation ».

4.3 PDF — le format pour geler une « version convenue »

L’impossibilité d’éditer facilement un PDF est à la fois un inconvénient et un avantage. Cela le disqualifie comme original d’un cahier des charges, mais le rend adapté comme instantané de la version ayant passé la recette, ou de la version convenue lors d’un changement de spécifications. Comme il ne peut pas être réécrit par inadvertance, il fait office de trace de « ce qui a été convenu à ce moment précis ».

Strictement parlant, un PDF peut néanmoins être recréé. Sa valeur en tant que trace ne vient pas du format PDF en lui-même mais du fait que les deux parties conservent le même fichier, il faut donc l’associer à des pratiques telles que l’envoi par e-mail avec conservation de la trace d’envoi, ou la conservation par chaque partie dans son propre environnement. Si l’on souhaite qu’il tienne comme preuve en cas de litige réel, l’ajout d’une signature électronique ou d’un horodatage est également une option.

Il y a un autre principe simple : le PDF doit toujours être accompagné de l’original modifiable. Livrer uniquement un PDF restreint les options futures du client (exploitation en interne, confiage de la maintenance à une autre société).

4.4 Garder la source en Markdown + Git, et livrer du Word / PDF généré

Du côté de la société de développement, il devient de plus en plus courant ces dernières années de rédiger les cahiers des charges en Markdown et de les versionner dans le même dépôt Git que le code source. Cela permet d’obtenir des différences ligne par ligne, de relire les documents avec le même mécanisme qu’une revue de code, et de conserver l’historique de chaque changement (ce qui suffit largement comme trace pour le travail quotidien de développement, mais si l’on a besoin que cela tienne comme preuve pour un audit ou un litige, il faut en plus une pratique interdisant la réécriture de l’historique).

Rien de tout cela n’exige de demander au client d’utiliser Git. En gérant la source en Markdown et en générant le Word ou le PDF de livraison avec un outil de conversion tel que Pandoc, le client reçoit simplement un Word ou un PDF comme d’habitude, sans rien de différent pour lui. Cela permet de concilier l’efficacité de gestion côté développeur et la lisibilité côté client.

Le point de vigilance est de rendre explicite, dans le contrat, « quel est le côté source de vérité ». Si le client modifie directement le fichier Word généré, celui-ci diverge de la source ; il faut donc un accord opérationnel — par exemple, recevoir les demandes de correction sous forme de commentaires et les répercuter dans la source.

4.5 Wiki / outils en ligne — un « cahier des charges vivant » en cas de maintenance continue

Pour un système sous contrat de maintenance continue avec des modifications fréquentes, tenir le cahier des charges constamment à jour dans un outil en ligne tel que Notion ou Confluence est aussi une option solide. La recherche y est efficace, l’historique des modifications est conservé automatiquement, et c’est un format qui facilite le maintien d’un « document vivant » plutôt que d’un document simplement « livré une fois pour toutes ».

Cependant, vu comme livrable, il faut décider dès le départ ce qu’il restera une fois le contrat terminé : le format d’export (peut-on exporter vers Word ou PDF), la propriété de l’espace de travail et sa prise en charge financière, et le traitement des comptes d’accès. Laisser ce point dans le flou expose à un verrouillage envers un outil particulier, avec un risque de perdre l’accès au document au moment même où le contrat se termine.

5. Comment gérer les échanges liés aux changements de spécifications

Même avec un format bien choisi, le problème de « quelle est la dernière version » réapparaît sans un processus opérationnel, car les spécifications continuent d’évoluer, aussi bien pendant le développement que pendant la phase de maintenance, et pas seulement jusqu’à la livraison. Voici la structure de base recommandée.

1. Tenir un seul registre de gestion des changements : une liste enregistrant, sur une ligne par entrée, le numéro de changement, la date, le contenu, l’impact (coût/délai) et qui a donné son accord. Un simple tableau Excel véritable suffit largement pour cela. Le mettre en correspondance avec la procédure de gestion des changements du modèle de contrat IPA (voir l’article mentionné plus haut).
2. Faire circuler les révisions de documents avec les différences visibles : pour Word, activer le suivi des modifications avant d’envoyer une version révisée, et laisser le client concentrer sa relecture sur les marques en rouge. Si l’on craint qu’un changement passe inaperçu faute d’avoir été suivi, la partie qui reçoit le document peut le détecter en utilisant la fonction « Comparer » de Word par rapport à la précédente version convenue. Une fois l’accord obtenu, accepter les modifications suivies et figer cette version.
3. Définir une règle de numérotation des versions : appeler v1.0 la version acceptée en recette, et l’incrémenter en v1.1, v1.2, etc. à chaque changement convenu. Ne jamais utiliser « final », « corrigé » ou « (2) » dans un nom de fichier.
4. Geler chaque version convenue en PDF, et la faire conserver par les deux parties : de sorte que n’importe qui puisse identifier après coup exactement quelle version a été convenue.

Quels que soient les outils utilisés, maintenir ces quatre points en place permet d’écarter presque entièrement les deux grandes catégories de problèmes : « on ne sait pas ce qui a changé » et « on ne sait pas quelle est la version convenue ». Autrement dit, l’accord sur les règles opérationnelles compte davantage que le choix de l’outil.

6. Ce que le client devrait vérifier avant de signer le contrat

À l’intention du client, voici sous forme de liste de contrôle ce qu’il convient de vérifier au stade du devis et du contrat.

• La liste des livrables inclut-elle le cahier des charges et les documents de conception au niveau du nom précis de chaque document (et non sous la forme vague d’un « ensemble de documentation ») ?
• Recevrez-vous un original modifiable (fichier Word/Excel, etc.) ? Se limite-t-on à un PDF seul ?
• Lorsque vous recevez une version révisée, est-elle présentée sous une forme montrant ce qui a changé (suivi des modifications, liste des sections modifiées) ?
• Le périmètre du contrat de maintenance inclut-il la mise à jour des documents lors d’une modification ? Si non, acceptez-vous que les documents s’écartent progressivement de la réalité ?
• Comment sont traités les droits d’auteur et la réutilisation du document ? Pourra-t-il être transmis si la maintenance est un jour confiée à une autre société ?
• La procédure de changement de spécifications (registre de gestion des changements, manière de conserver la trace de l’accord) est-elle définie ?

Du point de vue du prestataire aussi, cette même liste est directement utile pour structurer un devis. Décider quel document rédiger, avec quel niveau de détail, représente une charge de travail — donc un montant. Accepter un projet en laissant le périmètre des livrables dans le flou conduit, juste avant la livraison, à un malentendu du type « nous pensions que ce document était évidemment inclus ». S’accorder au préalable sur la liste et le format des documents protège les deux parties.

7. FAQ

Q1. Le client nous a imposé un modèle Excel « papier quadrillé ». Sommes-nous obligés de nous y conformer ?

Respecter le format de livraison imposé fait effectivement partie du travail du prestataire, mais il vaut la peine de vérifier l’objectif réel de cette exigence. Si le but est de respecter un standard documentaire interne ou une contrainte d’audit, il y a souvent moyen de proposer de satisfaire la même exigence avec un format Word, et il n’est pas rare que le modèle imposé ne soit qu’une habitude héritée du passé. Même lorsque le format ne peut pas être changé, des pratiques opérationnelles — joindre une « liste des sections modifiées » à chaque révision, geler les versions convenues en PDF — permettent d’atténuer la plupart des problèmes liés à l’impossibilité de visualiser les différences.

Q2. Nous n’avons reçu le cahier des charges qu’au format PDF. Est-ce un problème ?

Sur le moment, cela ne semble pas poser de problème puisque le document reste lisible, mais des difficultés apparaissent dès la phase de maintenance ou de modification. Éditer un PDF n’est pas impossible avec des outils spécialisés, mais continuer à le mettre à jour en préservant sa structure, comme on le ferait avec un original Word ou Excel, n’est pas réaliste, et l’écart avec l’implémentation se creuse à chaque changement de spécifications. Cela complique également la transmission du dossier si vous devez un jour confier la maintenance à une autre société, faute d’original modifiable. La solution fiable consiste à préciser dès la signature du contrat que « la livraison inclut un format modifiable » comme condition des livrables. Si vous n’avez reçu que le PDF, n’hésitez pas à demander l’original à la société de développement.

Q3. Jusqu’à quel niveau de détail le cahier des charges doit-il être rédigé ?

« Plus c’est détaillé, mieux c’est » n’est pas toujours vrai. Un document plus détaillé coûte plus cher à mettre à jour et s’écarte plus facilement de l’implémentation. Le repère à retenir est que le comportement doit être suffisamment précisé pour servir de base à la recette, et que les informations consultées lors de la maintenance ou des modifications (champs d’écran, structures de données, intégrations externes, règles métier) doivent être conservées. Une description ligne par ligne de l’implémentation, que l’on peut de toute façon retrouver en lisant le code, s’écarte moins de la réalité si elle vit dans le code et ses commentaires plutôt que dans un document. Le niveau de détail se traduit directement en charge de travail et en montant du devis : c’est un point à aligner avant la signature du contrat.

Q4. Après la livraison, à qui incombe la mise à jour du cahier des charges ?

Cela dépend du contrat. Si le périmètre du contrat de maintenance inclut « la mise à jour des documents de conception lors des modifications », c’est au prestataire de s’en charger ; sinon, soit la mise à jour documentaire fait l’objet d’une commande séparée à chaque modification, soit on accepte que le document s’écarte progressivement de la réalité. Le cas qui tourne le plus souvent au conflit est celui où aucune des deux parties ne tranche ce point et où chacune suppose que « bien sûr, c’est tenu à jour ». Lors de la signature d’un contrat de maintenance, il est recommandé de préciser, au niveau du nom de chaque document, lesquels entrent dans le périmètre de la maintenance.

Résumé

Voici un récapitulatif des points essentiels de cet article sur les cahiers des charges livrés dans le cadre d’un développement sous contrat.

• Choisir le format du cahier des charges livré en fonction de la recette, des changements de spécifications et de la maintenance — pas uniquement en fonction de « est-ce facile à écrire pendant le développement ».
• Les problèmes fondamentaux du papier quadrillé Excel sont une recette qui devient purement formelle et la perte de toute trace d’accord, tous deux dus à l’impossibilité de voir les différences, ainsi qu’un écart avec l’implémentation dû au coût élevé des mises à jour.
• La conclusion n’est pas « supprimer totalement Excel », mais revenir à remettre le bon outil au bon endroit : le texte dans Word (styles + suivi des modifications), les tableaux dans de véritables tableaux Excel, et la trace d’un accord gelée en PDF.
• Gérer la source côté développeur en Markdown + Git, et générer le Word/PDF comme livrable, permet de concilier les avantages des deux côtés.
• Avant le format, régler dans le contrat la liste des livrables, la livraison d’un original modifiable et le traitement des droits d’auteur. L’accord sur les règles opérationnelles compte plus que l’outil.

Par ailleurs, la lecture et l’écriture d’Excel depuis un programme (sortie d’états imprimés) sont traitées dans Construire une sortie d’états Excel - COM/Open XML/Modèles, et la structuration du contrat lui-même est traitée dans l’article expliquant le modèle de contrat de transaction de l’IPA. À lire en complément.

Pour ceux qui envisagent d’externaliser le développement ou la maintenance

Chez Komura Software LLC, lorsque nous prenons en charge le développement sous contrat d’applications métier Windows, nous avons pour pratique de convenir dès le départ avec le client du périmètre, du format et du processus de mise à jour des documents livrables, en suivant exactement la logique présentée dans cet article. Nous prenons également en charge, pour la modification de logiciels existants, des enquêtes partant d’un état où « le cahier des charges existe, mais on ne sait pas s’il correspond à la réalité ». N’hésitez pas à nous consulter, y compris pour la mise en ordre d’un cahier des charges ou la révision de son format de livraison.

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Le client nous a imposé un modèle Excel « papier quadrillé ». Sommes-nous obligés de nous y conformer ?

Respecter le format de livraison imposé fait effectivement partie du travail du prestataire, mais il vaut la peine de vérifier l'objectif réel de cette exigence. Si le but est de respecter un standard documentaire interne ou une contrainte d'audit, il y a souvent moyen de proposer de satisfaire la même exigence avec un format Word, et il n'est pas rare que le modèle imposé ne soit qu'une habitude héritée du passé. Même lorsque le format ne peut pas être changé, des pratiques opérationnelles — joindre une « liste des sections modifiées » à chaque révision, geler les versions convenues en PDF — permettent d'atténuer la plupart des problèmes liés à l'impossibilité de visualiser les différences.

Nous n'avons reçu le cahier des charges qu'au format PDF. Est-ce un problème ?

Sur le moment, cela ne semble pas poser de problème puisque le document reste lisible, mais des difficultés apparaissent dès la phase de maintenance ou de modification. Éditer un PDF n'est pas impossible avec des outils spécialisés, mais continuer à le mettre à jour en préservant sa structure, comme on le ferait avec un original Word ou Excel, n'est pas réaliste, et l'écart entre l'implémentation et le document se creuse à chaque changement de spécifications. Cela complique également la transmission du dossier si vous devez un jour confier la maintenance à une autre société, faute d'original modifiable à remettre. La solution fiable consiste à préciser dès la signature du contrat que « la livraison inclut un format modifiable (l'original Word ou Excel) » comme condition des livrables. Si vous n'avez reçu que le PDF, n'hésitez pas à demander l'original à la société de développement.

Jusqu'à quel niveau de détail le cahier des charges doit-il être rédigé ?

« Plus c'est détaillé, mieux c'est » n'est pas toujours vrai. Un document plus détaillé coûte plus cher à mettre à jour et s'écarte plus facilement de l'implémentation en phase de maintenance. Le repère à retenir est que le comportement doit être suffisamment précisé pour servir de base à la recette, et que les informations consultées lors de la maintenance ou des modifications (champs d'écran, structures de données, intégrations externes, règles métier) doivent être conservées. À l'inverse, une description ligne par ligne de l'implémentation, que l'on peut de toute façon retrouver en lisant le code, s'écarte moins de la réalité si elle vit dans le code et ses commentaires plutôt que dans un document. Le niveau de détail se traduit directement en charge de travail, donc en montant du devis : c'est un point à aligner avant la signature du contrat.

Après la livraison, à qui incombe la mise à jour du cahier des charges ?

Cela dépend du contrat. Si le périmètre du contrat de maintenance inclut « la mise à jour des documents de conception lors des modifications », c'est au prestataire de s'en charger ; sinon, soit la mise à jour documentaire fait l'objet d'une commande séparée à chaque modification, soit on accepte que le document s'écarte progressivement de la réalité. Le cas qui tourne le plus souvent au conflit est celui où aucune des deux parties ne tranche ce point et où chacune suppose que « bien sûr, c'est tenu à jour ». Lors de la signature d'un contrat de maintenance, il est recommandé de préciser, au niveau du nom de chaque document, lesquels entrent dans le périmètre de la maintenance.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.