Nous autorisions les appels HTTP des clients même s'ils ne précisaient pas de numéro de version. Par défaut la version était donc implicite, à savoir la dernière version publiée (latest).

‍

Notre API refuse maintenant les appels d'API lorsque le numéro de version (MAJOR.MINOR) n'est pas précisé. Nos consommateurs doivent donc explicitement préciser la version. Soit via un header (Accepter: application/vnd.maboite.vMAJOR.MINOR+json), soit via le chemin (e.g. /vMAJOR.MINOR), soit via un query parameter (?v=MAJOR.MINOR).

‍

Les dépendances du projet était en "*" (a-k-a "latest" a-k-a "utilise la dernière version publiée de cette dépendance"). D'une construction à l'autre, le projet pouvait ne plus être livrable.

‍

La gestion des dépendances du projet est maintenant explicite, la version de chaque dépendance est explicitement spécifiée en vX.Y.Z. L'équipe utilise un fichier de lock par projet (c.f. javascript, rust, ruby, php) pour assurer la reproductibilité des constructions.

‍

Pull d'une image de container (e.g. docker) sans préciser de tag. Cela revient à préciser le tag "latest", à savoir la dernière version publiée de l'image. Cet anti-pattern peut s'observer dans les fichiers docker-compose.yml, yaml Kubernetes ou encore pour la construction d'une image depuis un Dockerfile (FROM image).

‍

L'équipe précise maintenant explicitement le tag de chaque image dont son projet dépend et n'emploie plus le tag "latest".

‍

Configuration écrite en dur, cachée dans le code source du programme (e.g. identifiant d'accès à la base de données).

‍

Configuration via des variables d'environnements requises au démarrage du programme

‍

Voila ce qu'il se passe quand un standard (ASN.1 RFC2631) laisse passer l'implicite.