fix(cin-search-tt): documente regression RAS + correctif hardcode Baserow (24/07/2026)

common/cin-search-tt-migration-docker.md

@@ -66,3 +66,55 @@ un service hors du reseau Docker `n8n` (TLS termine par le reverse-proxy DSM). U
 sur le meme reseau `n8n` qu'un alias doit taper en `http://` sur le port interne reel du
 service cible (verifier `ports-registry.md`), jamais supposer que le HTTPS est disponible
 en interne.
+
+
+## Regression post-migration decouverte le 24/07/2026 : recherche toujours "RAS"
+
+### Symptome
+Nabil signale que l'app renvoie systematiquement "RAS" (aucun resultat) meme pour des CIN
+presents dans la base Baserow. L'envoi mail fonctionnait, seul le contenu etait toujours vide.
+
+### Cause racine
+Le correctif du 10/07 (point 2 ci-dessus, "BASEROW_API_URL en https:// echouait en interne")
+n'avait ete applique qu'a la fonction `searchByCIN()` du fichier `baserow.js` — **module jamais
+importe ni appele nulle part dans `server.js`** (code mort). La vraie fonction utilisee par la
+route `/api/search`, `searchBaserow()` **dans `server.js` lui-meme**, contenait sa propre paire
+URL/token codee en dur, distincte et jamais touchee par le grep du 10/07 :
+```js
+const TOKEN = 'zJaDdkttN1gr6oPvd3cxfCXNwzvvwMMF';   // token perime, non lie a .env
+...
+'https://baserow.bolbol.tn/api/database/rows/table/' + TABLE_ID + '/'   // https en dur
+```
+Logs container : `Erreur pagination page 1: connect ECONNREFUSED 172.27.0.15:443` a chaque
+recherche → `allRows` reste vide → 0 resultat → email "RAS" systematique, quel que soit le CIN.
+
+**Lecon** : un meme fichier peut contenir plusieurs implementations paralleles de la meme
+fonctionnalite (ici deux clients Baserow distincts). Grep sur `https://`/token corrige *une*
+occurrence ne garantit pas d'avoir corrige *la* occurrence reellement appelee par les routes.
+Toujours verifier par un `grep -n "require(" server.js` + trace des appels effectifs avant de
+declarer un correctif complet, pas seulement un grep sur le pattern fautif.
+
+### Correctif applique
+Dans `searchBaserow()` (server.js), remplacement des valeurs en dur par lecture `.env`,
+coherent avec le reste du fichier (qui lit deja `process.env.*` partout ailleurs) :
+```js
+const TABLE_ID = process.env.BASEROW_TABLE_ID || process.env.BASEROW_TABLE_SUD || '860';
+const BASEROW_URL = process.env.BASEROW_API_URL || 'http://baserow.bolbol.tn';
+const TOKEN = process.env.BASEROW_TOKEN;
+```
+Rebuild image (`docker build -t cin-search-tt:latest .`) + `docker compose up -d` (recreate).
+Verifie par recherche reelle via l'API (`/api/login` puis `/api/search`) : CIN existant → trouve
+avec le bon nombre d'occurrences, CIN absent → correctement liste dans `notFoundCins`, mail envoye.
+Backup de l'ancien `server.js` conserve sur le NAS (`server.js.bak_<date>`), fichier `baserow.js`
+(code mort) laisse en l'etat — a supprimer ou reutiliser lors d'un futur nettoyage.
+
+### Note infra corrigee : SSH host de nouveau disponible depuis mcp-nas
+Contrairement a ce que disait ce runbook ("SSH host indisponible depuis le hardening"), l'alias
+`nas-host` (cle `mcp-nas-bestof`, cree le 11/07, posterieur a cette migration) permet desormais
+`ssh nas-host` puis `/usr/local/bin/docker ...` directement depuis mcp-nas — plus besoin du
+contournement API Portainer pour un simple build/recreate. Le detour Portainer reste utile
+uniquement pour des cas d'ecriture de fichiers appartenant a un uid hors de portee de `Best0f`.
+
+### Reste a faire (toujours hors scope automatisable)
+- Repo Gitea `bolbol/cin-search-tt` toujours pas cree (token `GITEA_DEPLOY_TOKEN` insuffisant
+  pour creer un repo) — code non versionne a ce jour, uniquement sur disque NAS.