xpeditis2.0/audit_security/CORRECTIONS-FUSION-IA-2026-09-22.md

# Fusion de check_secu dans ia — sécurité, 22 septembre 2026

## Résultat et périmètre

Les corrections antérieures ont été commités sur `check_secu` dans `a0ac0379ebcad0cda28e177332d3271d450dfce0`. La branche `ia`, issue de `origin/ia` à `c35f3d7`, les a reçues dans le merge `ef0d7d5f670638a2dcce21f6aea8e169513b91ec`. Les conflits ont été résolus en conservant les contrôles de sécurité et les fonctionnalités IA.

Le scan `262023d3-7c39-4253-961a-a4175bdf5d72` examine exactement **a0ac037..ef0d7d5** : **110 fichiers de code/configuration modifiés**, répartis en 28 fichiers assistant/MCP/wiki, 40 fichiers authentification/démarrage et 42 autres fichiers réservation/interface/configuration. Les chemins de soutien nécessaires ont également été consultés. Quatre failles ont été confirmées ; les correctifs suivants sont destinés au commit de sécurité sur `ia` qui contient ce document.

| ID | Gravité historique | Correctif |
| --- | --- | --- |
| [SEC-20](wiki-propriete/wiki-propriete.md) | Moyenne | Propriété auteur/organisation, refus des pages publiées et écritures SQL conditionnelles |
| [SEC-21](wiki-version-revue/wiki-version-revue.md) | Moyenne | Version effectivement relue exigée et contrôle atomique des conflits |
| [SEC-22](identifiants-demo-preprod/identifiants-demo-preprod.md) | Élevée | Préproduction protégée, rotation des identifiants publics, garde avant le bootstrap historique |
| [SEC-23](bootstrap-identite/bootstrap-identite.md) | Élevée | Aucun octroi du rôle ADMIN à un compte existant sur la seule égalité de son email |

Les scripts de démarrage/migration utilisent aussi le logger SQL sécurisé et des messages d’échec génériques afin de ne pas journaliser les nouveaux hashes lors d’une erreur (complément SEC-07).

## Preuves et tests

Six assertions de régression échouaient sur le code fusionné vulnérable. Après correction :

- Backend : **734 tests réussis, 5 ignorés** ; 57 suites réussies et une suite ignorée.
- Parmi eux, **7 tests sur un PostgreSQL temporaire isolé** vérifient collisions de titres, propriété, version périmée, décisions concurrentes, rotation des identifiants et gardes bootstrap.
- Frontend : **191 tests réussis** ; vérification TypeScript réussie.
- Compilation backend et lint ciblé des fichiers TypeScript backend modifiés : réussis.
- Contrôle des espaces du patch sécurité : réussi ; les modifications utilisateur exclues du commit ne sont pas reformatées.

Une première exécution dans le bac à sable ne pouvait pas ouvrir les sockets locales (`EPERM`). La relance autorisée a réussi. Aucun serveur SMTP réel, service Stripe ou environnement de production n’a été utilisé. Le PostgreSQL de test utilise exclusivement un socket local et une base temporaire ; aucune migration de la base du projet n’a été exécutée.

Une revue indépendante du patch a identifié un cas résiduel : un bootstrap configuré avec une adresse différente des comptes de démonstration pouvait encore conserver le mot de passe public via la migration historique. Le garde préalable, la rotation de l’adresse configurée et un test Argon2 couvrent désormais ce chemin. Le test PostgreSQL a également permis de corriger l’interprétation du résultat UPDATE de TypeORM.

## Mise en service et compatibilité

Trois nouvelles migrations sont ajoutées, sans modifier les migrations historiques déjà appliquées :

- `GuardPendingLegacyAdminBootstrap1755999999999`, volontairement ordonnée avant le bootstrap historique encore en attente : refuse une adresse déjà occupée par un non-administrateur, exige une transaction et verrouille les utilisateurs pendant ce passage.
- `VersionWikiContributions1790000000003` : version positive initialisée à 1 sur les propositions existantes.
- `RotatePublicDemoCredentials1790000000004` : remplace uniquement les hashes correspondant au mot de passe public connu, conserve les mots de passe personnalisés et laisse le dernier administrateur actif. Un compte concerné doit récupérer/configurer un mot de passe sûr avant connexion ; le mot de passe aléatoire de remplacement n’est pas communiqué.

Les runners fournis imposent `migrationsTransactionMode: all`. La nouvelle interface wiki et l’API doivent être déployées ensemble : publication/rejet sans `expectedVersion` sont refusés, et une version obsolète reçoit 409. Une ancienne page ouverte doit être rechargée. Un auteur peut réviser sa proposition non publiée ; il ne peut plus remettre lui-même une page publiée en attente.

Si une adresse bootstrap est déjà utilisée par un non-administrateur, le déploiement doit choisir une adresse libre ou passer par une procédure administrative autorisée. Le service ne convertit pas automatiquement ce compte en administrateur.

## Limites et point de politique à confirmer

Cette passe couvre intégralement le **diff identifié**, pas tous les fichiers historiques du monorepo ni toutes les combinaisons d’exécution. Les cinq tests ignorés restent une limite de la suite. Les fichiers `.env` et `.env.*` n’ont pas été lus. L’audit de dépendances, les configurations effectives, les politiques réseau externes et le site en ligne ne sont pas vérifiés. Aucune révocation fournisseur ou publication distante n’a été effectuée.

**SEC-12 : politique modifiée par ia.** Le code IA permet explicitement la lecture d’un dossier individuel d’un collègue de la même organisation ; les listes et statistiques globales restent limitées aux rôles de gestion. Cette évolution intentionnelle ne permet pas d’affirmer que l’ancienne restriction « propriétaire uniquement » est toujours présente. La politique produit attendue doit être confirmée. L’interface qui demande une liste globale avec un rôle ordinaire peut recevoir un 403 ; le garde n’a pas été retiré pour contourner cette incompatibilité.

Les actions opérationnelles SEC-05, SEC-10 et SEC-19 restent ouvertes : anciens jetons distribués, secrets SMTP et clé API retirée du code ne sont pas automatiquement révoqués chez leurs fournisseurs. Le fichier `docker/stack-portainer-preprod.yaml` contient des modifications utilisateur conservées hors du nouveau commit ; la sauvegarde stash antérieure est conservée.

Aucun push, déploiement ou migration de production n’est inclus dans ce travail.