Dictionnaire de données

Dictionnaire de données : Inventaire commenté des champs et de leur signification, référence qui évite les interprétations divergentes entre équipes.

Le mot appartient à la famille « Technique » du lexique. Cette page dit ce qu’il recouvre, comment il se formule dans un cahier des charges, et ce qu’il vaut mieux ne pas écrire.

À quoi sert Dictionnaire de données

Sur un projet mobile, Dictionnaire de données se décide tôt. Revenir dessus après la mise en ligne suppose de toucher au serveur, aux applications déjà installées et parfois aux données déjà collectées.

Ce que le mot recouvre exactement dépend du projet. Ce qui suit vaut pour la plupart des applications mobiles françaises, et sert de point de départ à la discussion.

Comment l’écrire dans un cahier des charges

Un cahier des charges sérieux relie « Dictionnaire de données » à un critère de recette : une phrase que l’on peut cocher ou refuser, pas une intention.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les intégrations tierces, nommées, avec leur documentation et leurs limites d’appel.
• La sauvegarde des données : fréquence, durée de rétention, restauration réellement testée.
• La supervision : quelles alertes, vers qui, sous quel délai d’intervention.
• Le sort des données à la fin du contrat, format d’export compris.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Les contrôles à prévoir

À la recette, Dictionnaire de données se vérifie une fois avant la mise en ligne, puis à chaque version. Ces sujets se dégradent sans prévenir.

• Couper le réseau en pleine utilisation et regarder ce que l’application affiche.
• Tester sur une connexion lente, pas seulement sur le Wi-Fi du bureau.
• Lire les journaux d’erreurs de la première semaine de production.

Chacun de ces contrôles prend quelques minutes. Les découvrir après la mise en ligne prend des jours.

Les pièges à éviter

Aucune de ces erreurs ne se voit le jour où elle est commise. Toutes se paient plus tard, au moment le moins commode.

• Dimensionner l’infrastructure sur le trafic du lancement et non sur celui d’une campagne.
• Considérer les sauvegardes comme faites parce qu’elles sont configurées, sans tester de restauration.
• Découvrir les coûts d’hébergement après la mise en ligne, faute de les avoir demandés au devis.
• Mesurer la performance sur un téléphone récent et l’annoncer comme celle du parc réel.
• Reprendre la formulation d’un autre projet sans vérifier qu’elle décrit bien celui-ci.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• API REST
• Scalabilité horizontale
• Webhook
• Notification push

Questions fréquentes

Dictionnaire de données : de quoi parle-t-on exactement ?

Inventaire commenté des champs et de leur signification, référence qui évite les interprétations divergentes entre équipes. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

Quand faut-il en parler dans le projet ?

Au cadrage, avec les autres contraintes techniques. Une fois l’application en ligne, la même décision se paie en migration, en interruption de service et parfois en reprise des données déjà collectées.

Est-ce que ça se retrouve dans le devis ?

Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.