diff --git a/TODO.md b/TODO.md
index d80ab0f..07aea52 100644
--- a/TODO.md
+++ b/TODO.md
@@ -2,51 +2,30 @@
 
 ## Priorité haute
 
-### 1. Définir une politique d'exécution et de gestion d'erreur explicite
-- Documenter ce qui est considéré comme fatal vs best-effort
-- Définir si la séquence d'actions d'un hôte doit continuer après un échec
-- Standardiser les codes de sortie
-- Aligner le comportement réel, l'aide CLI et le README
-
-### 2. Sécuriser les zones sensibles de construction de commandes SSH
+### 1. Sécuriser les zones sensibles de construction de commandes SSH
 - Revoir les zones de quoting encore fragiles
 - Prioriser `cmd:<...>` et `docker-stacks:<...>`
-- Documenter des cas de test manuels pour les commandes avec espaces, pipes, redirections, `&&`, `||` et arguments quotés
 - Réduire le risque de régressions lors des prochains durcissements
 
 ## Priorité moyenne
 
-### 3. Améliorer le mode semi-automatisé / non interactif
-- Ajouter de vraies options batch-friendly, par exemple :
-  - `--all`
-  - `--no-log-view`
-  - `--keep-log`
-  - `--log-path <path>`
-- Clarifier la différence entre préselection interactive (`-f`) et exécution réellement non interactive
-
-### 4. Ajouter un minimum de validation et de qualité shell
+### 1. Ajouter un minimum de validation et de qualité shell
 - Ajouter de la guidance ShellCheck dans le projet
 - Envisager `shfmt` si cela reste léger
 - Ajouter des vérifications simples autour des fichiers de configuration sourcés
 - Rester incrémental, sans imposer brutalement un strict mode global
 
-### 5. Réduire progressivement la complexité du script principal
+### 2. Réduire progressivement la complexité du script principal
 - Extraire des helpers quand cela réduit la duplication sans casser le comportement
 - Simplifier les branches liées aux package managers
 - Garder des changements petits et relisibles
 
 ## Priorité basse
 
-### 6. Réfléchir à une configuration plus sûre si le projet grossit
+### 1. Réfléchir à une configuration plus sûre si le projet grossit
 - Le sourcing Bash reste acceptable tant que le modèle est assumé
 - Si le projet s'étend, envisager à terme un format déclaratif plus sûr
 
-### 7. Introduire des tests ciblés
-- Prioriser les tests de parsing
-- Ajouter des tests de construction de commandes
-- Couvrir les régressions connues autour du quoting SSH
-- Commencer petit plutôt que viser immédiatement une grosse suite end-to-end
-
 ## Rappels de conduite
 - Préserver la compatibilité des fichiers de configuration existants autant que possible
 - Préférer de petits commits logiques