Nordvantage Logistics SA

§ 0Ce que vous avez entre les mains

Cet audit n'a rien changé à ce que vous exploitez. Aucune configuration n'a été modifiée et aucun correctif n'a été appliqué. Chaque commande de ce rapport est en lecture seule et vous pouvez toutes les rejouer vous-mêmes. La seule exception est dite clairement parce qu'elle compte : le test de restauration (R-009) a provisionné une instance jetable, y a restauré une sauvegarde, et l'a détruite le jour même. Rien de ce qui est en service n'a été touché à aucun moment.

Contractuellement hors périmètre, donc absent : tout correctif, développement ou changement de configuration ; tests de sécurité applicative ; tests d'intrusion ; revue de code applicatif ; audit de conformité réglementaire. Là où un contrôle a frôlé l'un de ces sujets, la limite est indiquée au contrôle. DE-01 est le cas le plus net : j'ai lu quels chemins chaque merge request touchait, et le DDL de vos fichiers de migration. Je n'ai pas lu la logique applicative.

Chaque chiffre tiré de vos systèmes porte sa source en ligne. Les décomptes de mes propres contrôles, et mes estimations de l'effort de votre équipe, sont de moi et ne portent aucun marqueur. Ce sont les seuls nombres non marqués de ce document.

§ 1La version courte

Nordvantage exploite une plateforme de réservation et de suivi de fret sur GCP : deux clusters GKE Autopilot, nv-prod et nv-staging, portant 23 services kubectl · relevé du 13/05, une instance Cloud SQL PostgreSQL régionale, un cluster Kafka managé pour les événements transporteurs, et une instance GitLab auto-hébergée qui est à la fois votre source de vérité et votre chemin de déploiement. Une quarantaine d'ingénieurs déclaré · call 1, qui livrent chaque semaine avec des hotfixes au besoin.

J'ai passé 58 contrôles sur six domaines. 34 sont revenus conformes, 9 ont produit un constat, 2 ont produit un constat de coûts, 5 n'ont pas pu être tranchés en cinq jours, 8 ne s'appliquaient pas à votre installation.

Sur les 9 constats, 1 est classé Élevé, ce qui veut dire que j'ai observé chaque étape d'une séquence menant à une exposition d'identifiants, sauf l'événement déclencheur lui-même. C'est R-001, votre instance GitLab, et j'ai appelé Marc le 12 mai plutôt que de garder ça pour ce document. Fermer l'exposition coûte une demi-journée plus une fenêtre de maintenance. Les huit autres sont trois Moyens et cinq Faibles, listés en intégralité, chacun avec la raison pour laquelle il n'a pas passé la barre.

12 des 14 items du plan sur 90 jours sont des choses que votre équipe peut faire sans aide extérieure. Les cinq premières, qui ferment le constat Élevé et deux Moyens, représentent environ deux jours-personne plus une fenêtre de maintenance. Le reste s'étale sur le trimestre et chaque action porte sa propre estimation au §10. Les deux qui demandent une compétence que vous n'avez peut-être pas en interne sont nommées comme telles, avec la capacité précise écrite noir sur blanc.

En dehors du registre, la revue de facturation a identifié 7 164 € par an de dépense rattachée à des ressources qui ne servent rien, et 24 360 € de plus par an qui valent la peine mais demandent une décision de votre part. Les coûts ne sont pas du risque, donc rien de tout ça n'est dans le registre ; c'est au §7, avec la méthode qui l'a produit.

Deux conditions que j'ai soulevées mardi ne sont pas du tout dans le registre. Elles ont échoué à leur propre contre-argument et partent en rejets, parce qu'un registre qui ne fait que grossir est un document commercial.

§ 2Couverture

58 contrôles, pré-enregistrés et qui vous ont été envoyés le 6 mai, cinq jours avant le début de la semaine. Vous pouviez voir la liste avant que je ne voie vos systèmes. Cet ordre est voulu : il empêche que la liste de contrôles soit écrite à rebours, à partir de ce que j'aurais fini par trouver.

Quand un contrôle échantillonnait au lieu d'énumérer, la population, la taille de l'échantillon et la règle de sélection ont été notées au moment de l'échantillonnage. Rien ici ne reconstruit sa propre logique d'échantillonnage après coup, parce qu'une logique reconstruite est toujours flatteuse.

§ 3Ce qui fonctionne, et qu'il ne faut pas toucher

Un rapport qui n'est que constats est à la fois un document commercial et une description inexacte de votre plateforme. Les éléments ci-dessous sont porteurs, et je plaiderais contre le moindre changement sur chacun d'eux.

§ 4À ne pas faire

Deux choses qu'un trimestre plein de bonnes intentions pourrait produire, et qui rendraient votre plateforme pire.

Ne restreignez pas gitlab-deploy@ à objectViewer sans vérifier d'abord ce qu'il écrit

C'est le nettoyage qui a l'air évident, et il peut faire tomber la production. Avant d'y toucher, lancez git grep -nE 'terraform (plan|apply|init)' restreint aux jobs de déploiement, et lisez 90 jours de logs d'accès aux données du bucket, filtrés sur les écritures de ce principal. Si l'un des deux renvoie quoi que ce soit, le droit est porteur. Si vous le faites quand même, le rollback consiste à ré-accorder objectAdmin. Notez aussi que l'item 9 du plan met un job Terraform dans la CI ce trimestre, ce qui entrerait en collision avec le droit restreint.

N'adoptez ni modèle de maturité ni dashboard de scoring pour ce registre

Huit constats n'ont pas besoin d'une heat map, et dès qu'un registre a un score, c'est le score qu'on se met à gérer. Ceci est une liste de conditions précises avec des actions suivantes nommées, et elle doit le rester.

§ 5Si vous ne faites que trois choses

Cela représente une journée et demie du temps de votre équipe, plus une fenêtre de maintenance, et cela solde le seul Élevé ainsi que deux des trois Moyens.

Cette liste est ordonnée autrement que la liste courte à la fin du §10, délibérément. Ici, le classement se fait par réduction du risque. Là-bas, par ce qui tient dans un après-midi. R-002 est le plus gros chantier et il arrive troisième parce que l'item 1 n'en dépend pas : vous pouvez fermer l'exposition aujourd'hui, et mettre à niveau dans la fenêtre que vous avez déjà réservée.

§ 6Registre de risques

Les niveaux sont dérivés, pas choisis. Chaque entrée énonce une classe de conséquence et un grade de preuve du déclencheur, et le niveau est la lecture croisée des deux dans la table ci-dessous. Pour faire monter une entrée, je dois produire une preuve qui la déplace d'une case. Je ne peux pas taper un niveau à la main.

observed-in-window — la chaîne complète, événement déclencheur compris, s'est produite dans vos données, datée.
mechanism-present — chaque étape de la chaîne observée ; seul l'événement déclencheur absent.
hypothetical — au moins une étape de la chaîne est supposée plutôt qu'observée.

Notez ce que les deux dernières lignes suppriment : un agacement hypothétique n'est pas un constat, ce n'est rien. Deux conditions ont été écartées par cette règle cette semaine et figurent en §8.

4 des 9 entrées étaient déjà identifiées chez vous, dont 0 sur 1 Élevé. Sur ces quatre, l'apport est la datation, la conséquence et l'ordre, pas la découverte. 7 des 9 sont corrigeables par votre équipe seule.

# 1. Joignable de l'extérieur ? À lancer depuis une machine qui n'est PAS sur votre réseau.
curl -sS -o /dev/null -w 'HTTP %{http_code} from %{remote_ip}\n' \
  https://gitlab.nordvantage.example/users/sign_in

# 2. Quelles règles ingress créent un chemin public (périmètre : ingress seul, règles actives seules)
gcloud compute firewall-rules list \
  --filter='direction=INGRESS AND disabled=false AND sourceRanges:0.0.0.0/0' \
  --format='table(name,priority,network,targetTags.list(),
                  allowed[].map().firewall_rule().list())'

# 3. Ce qui s'applique réellement à l'instance, pas ce qui existe simplement dans le projet
gcloud compute instances network-interfaces get-effective-firewalls gitlab-01 \
  --zone=europe-west1-b \
  --format='table(type,direction,disabled,priority,sourceRanges.list())'

# 4. Les six variables, métadonnées seulement. jq supprime .value avant que quoi que ce soit ne touche le disque.
curl -sS -H "PRIVATE-TOKEN: $TOKEN" \
  'https://gitlab.nordvantage.example/api/v4/groups/nordvantage/variables?per_page=100' \
  | jq -r '.[] | [.key, .protected, .masked, .environment_scope] | @tsv'

# Le statut symbolique, et seulement ce qui n'est pas terminé. status_name évite
# l'enum numérique, qui est ce qui rend la table brute pénible à lire.
sudo gitlab-rails runner '
  Gitlab::Database::BackgroundMigration::BatchedMigration
    .where.not(status: :finished)
    .each { |m| puts [m.id, m.job_class_name, m.table_name,
                      m.status_name, m.updated_at].join("  ") }'

# Les jobs en échec sous l'une d'elles. `attempts` et l'exception vivent
# ici, sur la table des jobs, pas sur la ligne de la migration.
sudo gitlab-psql -c "select batched_background_migration_id as mig, status, \
  attempts, left(exception_class, 48) as exception, updated_at \
  from batched_background_migration_jobs \
  where batched_background_migration_id = 4291 \
  order by updated_at desc limit 10;"

gcloud compute ssh bastion-ops --tunnel-through-iap --command \
  '/usr/lib/update-notifier/apt-check --human-readable; uname -r; dpkg -l "linux-image-*" | tail -5'

kubectl get deploy,statefulset,daemonset -A -o json | jq -r '
  .items[] as $w
  | ($w.spec.template.spec.containers
     + ($w.spec.template.spec.initContainers // []))[]
  | select(.image | test("@sha256:") | not)
  | [$w.kind, $w.metadata.namespace, $w.metadata.name, .name, .image] | @tsv'

kubectl get deploy,statefulset,daemonset -A -o json | jq -r '
  .items[] as $w | $w.spec.template.spec.containers[]
  | [(.resources.requests.cpu // "unset"),
     (.resources.requests.memory // "unset")] | @tsv' \
  | sort | uniq -c | sort -rn

gcloud logging sinks list --format='table(name,destination,filter)'
gcloud logging buckets describe _Default --location=global --format='value(retentionDays)'

kubectl -n nv-staging get configmap integration-endpoints -o yaml

Une chose à accepter et à ne pas corriger

Le pont nv-edi n'utilise pas le template CI partagé, et il ne faut pas l'y forcer. C'est le connecteur EDI historique, il se déploie deux fois par an, et son pipeline fait 40 lignes qu'une personne comprend GitLab · .gitlab-ci.yml, 13/05. Le migrer coûterait plusieurs jours pour acheter de la cohérence sur un service dont toute la valeur est de ne pas avoir changé depuis 2023. Consigné ici pour que la prochaine personne qui greppe les pipelines non conformes n'y passe pas un sprint.

§ 7Ce que ça vous coûte, et ce qui n'a pas besoin de coûter

Les coûts ne sont pas des risques, donc rien de tout ceci ne figure au registre. C'est ici parce que c'est la partie de la semaine qui porte un chiffre, et parce que le premier tableau reste vrai quoi que vous décidiez par ailleurs.

Comment ces chiffres ont été produits. Chaque ligne vient de l'export de facturation, comparé mois par mois sur les trois mois jusqu'au 30 avril export de facturation GCP. Quand une ligne a grossi parce que vous avez livré davantage, cette croissance est isolée et n'est pas comptée comme du gaspillage. Votre plateforme a coûté 14 200 € par mois en moyenne sur cette fenêtre export de facturation GCP.

Supprimable dès maintenant, sans argument contre

Chacune de ces lignes est une ressource rattachée à rien, qui ne sert aucune requête. Il n'y a pas de contre-argument à formuler, et c'est pour ça qu'elles sont séparées du tableau qui suit.

Une précaution sur la ligne des images. R-004 a constaté que 9 des 23 workloads tirent leurs images par tag mutable, donc une politique de nettoyage non ciblée peut supprimer une image dont la production aura besoin au prochain rescheduling d'un pod. Comparez d'abord le registry à l'ensemble en service et ne supprimez que les digests non référencés. C'est quinze minutes, pas une décision, et c'est pour ça que la ligne reste dans ce tableau plutôt que dans le suivant.

Ça représente 4,2 % de votre facture mensuelle et environ deux heures de travail. C'est l'item 1 du plan sur 90 jours pour cette raison : rien là-dedans ne demande de décision à personne.

À faire, mais chaque ligne demande une décision

Ces lignes sont plus grosses et aucune n'est gratuite. L'argument contre chacune est réel, et je l'énonce plutôt que de vous laisser le trouver.

Non chiffré, délibérément

R-005 — Dimensionnement des requests Autopilot. La réservation, c'est la facture, mais la direction n'est pas uniforme : deux services ont besoin de plus. Pas de chiffre tant que la vue d'utilisation sur 30 jours n'existe pas, c'est l'item 11 du plan.

U-001 — Provisionnement Kafka. Le débit est mesuré ; le plancher fixé par les partitions, la réplication et la rétention ne l'est pas. Chiffrer une économie avant d'avoir répondu à ça, ce serait avancer un nombre que je ne peux pas défendre.

§ 8Examiné et non retenu

Des choses que j'ai contrôlées et qui se sont révélées conformes, et deux conditions qui sont mortes de leur propre contre-argument. Les deux étaient sur ma liste mardi. Aucune des deux n'a passé le jeudi.

Contrôlé et conforme, en bref : clés de comptes de service gérées par l'utilisateur (aucune) · âge des clés de comptes de service · ACL publiques de buckets (aucune) · scan de secrets sur l'ensemble des 23 dépôts · protection de branche sur main à l'échelle du groupe · drift Terraform sur le plan nocturne · actualité et profondeur du planning d'astreinte · réglages d'approbation des merge requests · scoping des tags de runners · IP publique Cloud SQL (désactivée) · héritage des org policies sur le dossier de production.

§ 9Ce que je n'ai pas pu déterminer en cinq jours

Cinq contrôles n'ont pas abouti. Cette section est une propriété d'un audit de cinq jours, pas un aveu. Notez ce qui ne figure pas ici : la question de savoir si vos sauvegardes se restaurent. Elle trouve sa réponse dans R-009, parce que le test de restauration est dans le périmètre.

§ 10Le plan sur 90 jours

Classé par valeur rapportée à l'effort. 12 des 14 items sont à faire chez vous, sans moi. Les deux marqués flochai nomment la capacité plutôt que l'entreprise, pour que vous puissiez chiffrer l'embauche de cette capacité face à son achat.

Jours 1 à 14 — configuration uniquement, chaque item se ferme en une après-midi

Jours 15 à 45

Jours 46 à 90

Si vous ne pouvez pas y consacrer six jours

Faites les items 1, 2 et 3. C'est une après-midi plus une fenêtre. Ça clôt l'Élevé, un Moyen, et l'intégralité du premier tableau de coûts. Ce n'est pas le même ensemble qu'au §5, et la différence est délibérée : le §5 classe par réduction du risque, ici on classe par ce qui tient dans une après-midi. R-002 est le chantier le plus gros et sa valeur dépend de la mise à niveau effectivement tentée, donc si vous avez une après-midi plutôt que trois, achetez d'abord la fermeture de l'exposition.

Pas dans les 90 jours, et pourquoi

Migrer nv-edi vers le template partagé (accepté, §6). Un notificateur de chat pour la CI (rejeté, §8). Des objectifs de latence par service au-delà des deux de U-004 : c'est un trimestre à part entière, qui ne devrait pas démarrer dans le même trimestre que le chantier de dimensionnement.

§ 11Méthode, et comment contester ce document

Une personne seule ne peut pas avoir de séparation des tâches. Voici le substitut honnête.

La liste de contrôles a été figée avant la semaine. 58 contrôles, liste envoyée le 06/05. Les constats ne pouvaient sortir que de cette liste, ce qui empêche de l'écrire à rebours à partir de ce que j'ai trouvé.

La sévérité est une lecture de table, pas une opinion. Chaque entrée énonce ses deux paramètres. Si vous n'êtes pas d'accord avec un niveau, attaquez l'un des deux paramètres : il y a alors une chose définie à débattre, plutôt qu'un ressenti à marchander.

Le registre a été gelé vendredi à 17 h 00 et les accès ont pris fin lundi. Une idée sans preuve le mardi n'est pas un constat, et rien n'a été ajouté après le gel. Le plan sur 90 jours a été écrit après, délibérément, pour que la sévérité ne puisse pas être ajustée après coup pour coller à un plan.

Vous l'avez contesté jeudi. Le call n°2 a mis le brouillon du registre sous vos yeux alors qu'il restait un jour ouvré pour agir sur une rétrogradation. R-002 est passé d'Élevé à Moyen en conséquence directe, et la raison est écrite dans l'entrée. Ce que vous n'avez pas vu avant le gel : les cinq entrées Faible et les deux rejets, que j'ai mentionnés jeudi mais sans les dérouler ligne à ligne.

Je ne chiffre pas les conséquences en euros, parce que je ne connais pas votre chiffre d'affaires horaire. Je chiffre en revanche les économies en euros, à partir de votre propre facture fournisseur, et le §7 est le seul endroit où ça se produit.

Les corrections sont gratuites pendant 30 jours après la livraison. Ensuite, le registre est à vous. Chaque entrée porte une commande que vous pouvez relancer seul ; une entrée qui renvoie encore la même réponse dans six mois, sans que rien ne se soit produit ni déclenché, signifie que je me suis trompé sur elle. Vous n'avez pas besoin de moi pour le voir.

Le call de restitution

Une heure, ordre du jour fixé : R-001 et sa fenêtre, puis R-002 parce que l'item 6 en dépend, puis les deux items flochai pour que vous puissiez décider s'ils valent une aide extérieure ou une embauche. Dix minutes à la fin pour les rejets, parce que la façon dont un constat se fait tuer vous est plus utile que la façon dont il se fait lever.

Merci de révoquer mes accès à la fin de ce call, pas avant. Je me suis engagé à corriger tout ce que vous pouvez réfuter pendant 30 jours, et il faut que je puisse vérifier.

AnnexeAccès, preuves et contrôles

Accès demandés, accordés et refusés

Délibérément non demandés : accès aux données de la base de production ; code source applicatif au-delà de la configuration CI et du DDL de migration ; Auth0 read:users ; données clients de toute nature.

Preuves

71 pièces, archivées automatiquement au fil de l'exécution des commandes. Rien de non nettoyé n'a touché le disque. Le scrubber s'exécute avant toute écriture, et l'outil de capture s'arrête s'il est absent. Le smoke test du jour 1, lancé avant toute autre commande : une fausse clé AWS passée dans l'outil a produit une pièce archivée contenant AWS_KEY_REDACTED. S'il avait échoué, rien d'autre n'aurait tourné.

Valeurs des secrets. Pour GCP, la capture est sans valeurs par construction, parce que le rôle détenu ne peut pas lire les payloads des secrets. Pour GitLab, ce n'est pas vrai : l'endpoint des variables renvoie les valeurs. La capture a été filtrée au niveau de la commande pour qu'aucune valeur n'atteigne le disque, le droit était limité à CI-01, et borné dans le temps du 12/05 au 15/05.

Données personnelles. Le bundle contient des données personnelles : identités IAM, participants aux incidents, identifiants de routage des alertes. Il est chiffré pour votre clé, la copie locale est détruite 30 jours après la livraison, et les clauses de traitement des CGV signées s'y appliquent.

Les 58 contrôles — lignes représentatives