Faire ajouter ou modifier une structure de données

Quand l’employer

À employer avant tout changement de la forme des données, y compris l'ajout d'un simple champ. À ne pas employer pour une modification qui ne touche que l'affichage.

Les 5 trous à remplir avant d’envoyer

Chaque trou est une décision déjà prise. Un trou que vous ne savez pas remplir n’est pas une case à improviser : c’est un travail de cadrage qui manque.

{INFORMATION_A_STOCKER}

Quelle information faut-il conserver, et qui la produit ?

Pourquoi ce trou existe. Une donnée stockée sans producteur identifié reste vide en production et personne ne s'en aperçoit avant le premier rapport.

Si vous ne savez pas répondre. Trouvez le geste humain ou le calcul qui crée cette valeur. S'il n'existe pas, le champ ne sert à rien pour l'instant.

{OBLIGATOIRE_OU_FACULTATIF}

Cette information est-elle obligatoire, et que fait-on des enregistrements qui ne l'ont pas ?

Pourquoi ce trou existe. Rendre un champ obligatoire sans traiter les enregistrements existants fait échouer la mise en service, souvent en silence.

Si vous ne savez pas répondre. Considérez qu'il est facultatif. Le rendre obligatoire plus tard est possible, l'inverse coûte une reprise de données.

{CARACTERE_PERSONNEL}

Cette information permet-elle d'identifier une personne, directement ou par recoupement ?

Pourquoi ce trou existe. La qualification se fait avant l'écriture. Une donnée personnelle stockée par accident se supprime mal et se journalise partout.

Si vous ne savez pas répondre. En cas de doute, traitez-la comme personnelle. Le coût de la prudence est faible, celui de l'erreur ne l'est pas.

{QUI_PEUT_LA_LIRE}

Qui a le droit de lire cette information, et qui a le droit de la modifier ?

Pourquoi ce trou existe. Une donnée dont les droits ne sont pas décidés est une donnée lisible par tous, parce que c'est le réglage le plus simple à écrire.

Si vous ne savez pas répondre. Partez du principe que personne n'y a accès, puis ouvrez profil par profil. L'inverse laisse toujours une porte ouverte.

{RETOUR_ARRIERE}

Comment revient-on en arrière si ce changement de structure pose problème ?

Pourquoi ce trou existe. Un changement de structure sans retour arrière préparé transforme un incident mineur en indisponibilité longue.

Si vous ne savez pas répondre. Exigez que le changement soit additif : on ajoute, on ne supprime pas, on ne renomme pas. Un ajout se retire, un renommage se rattrape mal.

Le corps du gabarit

Quatre parties, toujours dans cet ordre : le rôle et le mandat, le contexte factuel, la demande bornée, le format de sortie exigé. Les trous restent visibles à la copie, et c’est voulu : les remplir un par un est la dernière occasion de s’apercevoir qu’une décision manque.

## 1. RÔLE ET MANDAT

Tu es ingénieur données. Ton mandat est de faire évoluer la structure des données de façon additive et réversible. Une structure de données est ce qui survit à toutes les versions du logiciel : elle se modifie avec plus de précaution que le reste.

## 2. CONTEXTE FACTUEL

Information à conserver et son producteur : {INFORMATION_A_STOCKER}
Caractère obligatoire et sort des enregistrements existants : {OBLIGATOIRE_OU_FACULTATIF}
Caractère personnel de la donnée : {CARACTERE_PERSONNEL}
Droits de lecture et de modification : {QUI_PEUT_LA_LIRE}
Retour arrière prévu : {RETOUR_ARRIERE}

Le changement est additif. Tu n'as le droit ni de supprimer une colonne existante, ni d'en renommer une, ni de changer le type d'une donnée déjà utilisée, même si la forme actuelle te paraît mauvaise.

## 3. DEMANDE BORNÉE

Fais évoluer la structure, de façon additive.

Ce que je veux :
1. la modification de structure, écrite dans un fichier de migration séparé et daté ;
2. l'énoncé, en français, de ce que la migration fait, avant le code de la migration ;
3. le comportement appliqué aux enregistrements existants, écrit et exécuté par la migration elle-même ;
4. les droits de lecture et de modification, posés explicitement, jamais laissés par défaut ;
5. la procédure de retour arrière, écrite et exécutable ;
6. la liste de ce qui, dans le reste du code, devra être adapté ensuite, sans le faire maintenant.

Ce que je ne veux pas : une suppression, un renommage, un changement de type sur une donnée existante, une modification appliquée directement à la base sans fichier de migration, une adaptation du reste du code dans le même envoi.

## 4. FORMAT DE SORTIE EXIGÉ

L'énoncé en français précède le code. La migration et son retour arrière sont deux blocs distincts. Si le retour arrière ne peut pas être écrit, tu me le dis clairement au lieu d'en écrire un qui ne fonctionne pas.

Ta réponse est refusable si elle supprime ou renomme quoi que ce soit, si les droits ne sont pas posés explicitement, ou si la procédure de retour arrière est absente ou décorative.

Ce que vous devez recevoir

• Un fichier de migration séparé et daté, jamais une action directe sur la base.
• Un énoncé en français de ce que fait la migration, placé avant le code.
• Un traitement appliqué aux enregistrements existants, exécuté par la migration.
• Des droits de lecture et de modification posés explicitement, profil par profil.
• Une procédure de retour arrière écrite et exécutable, ou un aveu clair qu'elle est impossible.
• La liste des adaptations à faire ensuite dans le reste du code, non faites maintenant.

Ce qui doit vous faire refuser

Ces motifs sont écrits comme des constats : « un fichier hors périmètre a été modifié » se vérifie, « le travail manque de rigueur » ne se vérifie pas.

• Une colonne existante a été supprimée, renommée, ou son type a changé.
• Le changement a été appliqué directement à la base, sans fichier de migration conservable.
• Les droits de lecture ne sont pas posés, ce qui rend la donnée lisible par défaut.
• Le retour arrière est mentionné sans être écrit, ou écrit sans être exécutable.
• Le sort des enregistrements existants est laissé à la charge d'une action manuelle non décrite.
• Une donnée personnelle est stockée sans que son caractère personnel soit tranché.
• L'agent a adapté le reste du code dans le même envoi, mélangeant structure et usage.

Selon pour qui vous construisez

Pour mon employeur.

Une donnée personnelle nouvelle se déclare auprès de la personne responsable de la conformité avant la mise en service, pas au moment du premier contrôle.

Pour un client.

La liste des données personnelles collectées pour le compte du client est tenue à jour et remise avec le produit. Elle vous protège autant qu'elle le protège.