Audit Helix
DE51 — Vincent Hilaire
Arnaud Michel · Benjamin Groisne · Antoine Laurant
Qu'est-ce qu'Helix ?
Éditeur modal pour le terminal
- Développé en Rust
- Inspiré de Vim et Kakoune
- Paradigme selection-first
"Batteries included"
- LSP intégré nativement
- Tree-sitter intégré
- Aucun plugin requis
Philosophie
Là où Vim et Neovim nécessitent des heures de configuration, Helix propose un environnement fonctionnel et performant prêt à l'emploi.
Périmètre et méthode
6 dimensions auditées
| Code source |
| Application |
| Site web |
| Documentation |
| Issues et Pull Requests |
| GitHub Discussions |
Approche SCAMPI adaptée
- Barèmes sur pratiques observables, indépendants de la taille du projet
- Commandes CLI déterministes (
cargo fmt,cargo clippy,cargo audit) - Protocoles de test manuels documentés
- Échantillonnages définis à l'avance
- Normalisation sur 20 pts pour le diagramme de Kiviat
Code source
| Critère | Note | Max |
|---|---|---|
| Lisibilité du code | 2 | 3 |
| Architecture | 2 | 3 |
| Gestion des dépendances externes | 1 | 3 |
| Gestion des erreurs et robustesse | 2 | 3 |
| Pratiques CI/CD et versionnement | 2 | 3 |
| Documentation du code | 1 | 3 |
| Tests | 2 | 3 |
| Sécurité du code | 1 | 3 |
| Maintenabilité | 2 | 3 |
| Sous-total | 15 | 27 |
Code source — Points positifs
Lisibilité
cargo fmtenforced en CI- Noms auto-documentants
- 14 fonctions dépassant le seuil de complexité — justifiables
Architecture
- 6 crates aux responsabilités distinctes
- Graphe de dépendances acyclique
- Structure lisible sans documentation externe
CI/CD
- Build, tests, fmt, clippy en CI
- CHANGELOG complet pour toutes les releases
- Tags SemVer stricts
Code source — Angles morts critiques
Sécurité (1/3)
- 13 blocs
unsafesur 15 sans commentaire// SAFETY: - Aucun
SECURITY.md - CVE non résolue détectée manuellement
cargo auditabsent de la CI
Documentation interne (1/3)
- Quasi-absence d'exemples dans les
/// - Sections
# Errorsinexistantes (2 occurrences seulement) - Modules internes non documentés
Dépendances (1/3)
- Aucune vérification de licence
- Pas de Dependabot ni Renovate
cargo audithors CI
Application
| Critère | Note | Max |
|---|---|---|
| Fonctionnalités d'édition core | 2 | 3 |
| Language Server Protocol | 3 | 3 |
| Tree-sitter | 3 | 3 |
| Modèle modal et keybindings | 3 | 3 |
| Portabilité multi-plateforme | 3 | 3 |
| Interface utilisateur | 3 | 3 |
| Sous-total | 17 | 18 |
Application — Points clés
LSP — 3/3
- rust-analyzer, pyright, typescript-language-server : entièrement opérationnels
- Récupération automatique après
kill -9en moins de 5 secondes - Latence médiane inférieure à 200 ms
Tree-sitter — 3/3
- Coloration précise sur 5 langages : Rust, Python, TypeScript, Java, OCaml
- Erreurs de syntaxe localisées, sans effet cascade
- Text objects et mouvements AST cohérents
Modal et UI — 3/3
- Keybinding "rename symbol" trouvé en 45 secondes via les outils intégrés
- Thème daltonien dédié (
github_dark_tritanopia) - Comportement identique sur Debian, Ubuntu, Fedora et Windows 11
Seul comportement instable reproduit : crash sur usage intensif des macros avec fichiers volumineux.
Site web
Score parfait — 10/10
Clarté du message (2/2)
En quelques secondes depuis la page d'accueil : ce qu'est Helix, en quoi il diffère de Vim, pour qui il est fait.
Installation (3/3)
Accessible en un clic. Méthodes distinctes selon le profil utilisateur (cargo, paquet système, binaire). Les trois OS couverts.
Navigation (3/3)
Site responsive. Documentation, keybindings et CHANGELOG accessibles depuis le header. Moteur de recherche intégré dans la documentation.
Documentation
| Critère | Note | Max |
|---|---|---|
| Complétude | 4 | 4 |
| Cohérence avec l'application | 2 | 3 |
| Organisation et navigation | 3 | 3 |
| Qualité des exemples et des explications | 1 | 3 |
| Accessibilité aux débutants | 2 | 3 |
| Mise à jour et versioning | 1 | 2 |
| Sous-total | 13 | 18 |
Documentation — Analyse
Points forts
- Complétude totale : 15/15 fonctionnalités couvertes
- Toutes les options
config.tomldocumentées avec valeurs et défauts - Navigation efficace : 5 recherches abouties en moins d'une minute
- Moteur de recherche pertinent
Points faibles
- Quasi-absence d'exemples de workflow sur les fonctionnalités non triviales (multi-curseurs, macros,
%s) - Tutoriel interactif (
hx --tutor) inaccessible depuis le site - Guide de migration Vim hors de la documentation officielle
- Aucune indication de version dans la documentation
- Incohérence sur
mic: documenté comme "bloc", étiqueté "Comment" dans l'interface
Issues et Pull Requests
| Critère | Note | Max |
|---|---|---|
| Qualité du triage des issues | 1 | 3 |
| Réactivité des mainteneurs sur les issues | 2 | 3 |
| Qualité du processus de contribution (PR) | 3 | 3 |
| Transparence sur les décisions et la roadmap | 1 | 3 |
| Sous-total | 7 | 12 |
Réactivité sur les issues bug
Triage (1/3)
- 83,3 % des issues ont au moins un label
- Application incohérente : bugs non marqués
bug, labels génériques - Issues similaires avec labels différents sans logique identifiable
Réactivité (2/3)
- Médiane (si répondue) : 2h39
- Médiane globale avec les non-répondues : 162h (6,75 jours)
Pull Requests et transparence
Processus de contribution (3/3)
- 20 PRs externes analysées
- Délai médian avant première review : 2 jours 22 heures
- 11 fusionnées, 9 fermées sans merge
- Reviews constructives avec justifications
- CONTRIBUTING.md complet
Transparence sur la roadmap (1/3)
- Aucune roadmap publique formelle (assumé dans l'issue #5877)
- Aucun milestone GitHub actif
- Décisions architecturales dispersées dans des issues isolées
- 45 % des PRs refusées sans visibilité préalable sur le périmètre accepté
GitHub Discussions
| Critère | Note | Max |
|---|---|---|
| Activité et vitalité de la communauté | 2 | 3 |
| Qualité des réponses | 2 | 3 |
| Présence et rôle des mainteneurs | 1 | 3 |
| Organisation et découvrabilité | 2 | 2 |
| Sous-total | 7 | 11 |
Communauté autonome
- 14 discussions sur les 30 derniers jours
- 71,4 % reçoivent au moins une réponse
- 90 % des réponses proviennent de la communauté, non des mainteneurs
Mainteneurs peu proactifs (1/3)
- Présence ponctuelle, sans rôle structurant
- Discussions non utilisées pour les annonces ou le partage de vision
Synthèse globale
| Dimension | /20 |
|---|---|
| Code source | 11,1 |
| Application | 18,9 |
| Site web | 20,0 |
| Documentation | 14,4 |
| Issues et Pull Requests | 11,7 |
| Discussions | 12,7 |
| Total | 69 / 96 |
Lecture du diagramme
Ce que voit l'utilisateur
Application (18,9/20) et Site web (20/20) forment un pic net. L'énergie du projet s'est concentrée sur ce qui est perçu directement — le résultat est à la hauteur de l'ambition.
Ce que ne voit pas l'utilisateur
Code source (11,1/20), gouvernance (11,7/20) et communauté (12,7/20) creusent un déficit symétrique. Ces lacunes ne freinent pas les utilisateurs — elles freinent les contributeurs, exposant le projet à une dépendance croissante sur un noyau restreint de mainteneurs.
Propositions d'amélioration
Proposition 1
Sécurisation et robustesse critique du code source
Proposition 2
Mise en place d'un espace de suivi public de l'avancement du projet
Proposition 1 — État des lieux
Déficit de contrôle automatisé
Absence de cargo audit et cargo deny en CI. Les vulnérabilités et les licences non conformes ne sont pas bloquées automatiquement.
Gestion mémoire opaque
13 blocs unsafe sur 15 sans commentaire // SAFETY:. Zone d'ombre critique pour toute contribution externe.
Instabilité des services core
- Crash LSP silencieux — l'utilisateur continue à éditer sans autocomplétion ni diagnostics
- Crash système lors d'un usage intensif des macros sur fichiers volumineux
Absence de politique de sécurité
Aucun SECURITY.md. Les chercheurs en sécurité n'ont pas de canal de signalement responsable.
Proposition 1 — Plan d'action
Phase 1 — Industrialisation CI/CD (2 semaines)
- Intégration de
cargo auditen CI avec blocage sur CVE de sévérité medium ou supérieure - Configuration de
cargo denyavec liste blanche de licences (MIT, Apache-2.0, ISC, MPL-2.0) - Rédaction du
SECURITY.mdavec procédure de divulgation responsable
Phase 2 — Hardening et standardisation sécurité (4 semaines)
- Documentation de tous les blocs
unsafeavec invariants// SAFETY: - Standardisation des types d'erreur avec
thiserrorsur l'ensemble du workspace
Phase 3 — Robustesse opérationnelle (5,5 semaines)
- Correction du crash LSP silencieux avec notification visuelle à l'utilisateur
- Correction du crash macro sur fichiers volumineux avec test de régression associé
Proposition 1 — Planification
| Phase | Profil | Effort |
|---|---|---|
| Phase 1 | Ingénieur DevOps | 0,5 HM |
| Phase 1 | Expert Rust | 0,2 HM |
| Phase 2 | Expert Rust | 0,8 HM |
| Phase 2 | Ingénieur DevOps | 0,2 HM |
| Phase 3 | Expert Rust | 1,0 HM |
| Phase 3 | Ingénieur DevOps | 0,3 HM |
| Total | 3,0 HM | |
6 semaines calendaires · 2 experts · 40 700 €
Expert Rust senior : 650 €/j × 44 j
Ingénieur DevOps senior : 550 €/j × 22 j
Proposition 1 — Indicateurs de succès
| Indicateur | Cible |
|---|---|
Blocs unsafe documentés avec // SAFETY: | 100 % |
| CVE ouvertes bloquant la CI | 0 |
| Licences non conformes détectées en CI | 0 |
| Crashs LSP sans notification visuelle | 0 |
| Crashs macro sur fichiers de plus de 10 000 lignes | 0 |
Proposition 2 — État des lieux
Roadmap absente
Assumé dans l'issue #5877 : projet bénévole sans engagements formels. Les contributeurs potentiels n'ont aucune visibilité sur les priorités.
Milestones inexistants
Aucun milestone GitHub actif. Il est impossible de savoir ce qui est prévu pour la prochaine release.
Décisions architecturales dispersées
Refus de fonctionnalités et choix de conception dans des issues isolées, introuvables sans connaître déjà le projet en profondeur.
Frustration des contributeurs externes
45 % des PRs externes refusées. Sans visibilité préalable sur le périmètre accepté, une partie de ces refus était prévisible et évitable.
Proposition 2 — Solution
S'appuyer sur GitHub Projects — déjà dans l'écosystème, sans outil externe à adopter.
GitHub Projects public
4 colonnes : Backlog, En cours, En review, Livré.
Alimenté lors du triage habituel — déplacer une carte, pas écrire un commentaire.
Document "Non-Goals"
Centraliser les fonctionnalités explicitement hors périmètre, avec lien systématique dans les refus. Évite que les contributeurs travaillent sur des PRs vouées au refus.
Label "accepted-in-principle"
Signale les issues acceptées en attente d'un contributeur. Complété par le pinning de discussions de référence sur les choix architecturaux majeurs.
Proposition 2 — Planification
| Tâche | Durée | Effort |
|---|---|---|
| GitHub Project + 4 colonnes | 1 sem. | 0,1 HM |
| Document "Non-Goals" | 1 sem. | 0,1 HM |
| Label + protocole de triage | 0,5 sem. | 0,05 HM |
| Pinning des discussions | 0,5 sem. | 0,05 HM |
| Total | 3 sem. | 0,3 HM |
1 Tech Lead / Project Manager
Coût estimé : 6 500 €
Faible effort, impact direct sur l'attractivité des contributions.
Proposition 2 — Indicateurs de succès
| Indicateur | Cible |
|---|---|
| GitHub Project public actif avec au moins 10 issues tracées | Atteint |
| Document "Non-Goals" publié et référencé dans CONTRIBUTING | Atteint |
| Label "accepted-in-principle" utilisé sur au moins 5 issues existantes | Atteint |
| PRs externes refusées sans explication documentée | 0 % |
| Discussions de référence épinglées sur les choix architecturaux | ≥ 3 |
Conclusion
Un projet à la hauteur de son ambition utilisateur
Helix tient ses promesses en tant qu'éditeur. Application robuste, intégration LSP et Tree-sitter remarquables, site web exemplaire. Ce que l'utilisateur perçoit directement est excellent.
Une infrastructure interne à consolider
Sécurité, documentation interne, gouvernance. Ces lacunes ne freinent pas les utilisateurs aujourd'hui. Elles fragilisent les contributeurs et exposent le projet à une dépendance croissante sur un noyau restreint de mainteneurs.
Deux propositions ciblées : sécurité CI/CD (~40 700 €, 3 HM) et transparence (~6 500 €, 0,3 HM) pour rééquilibrer le Kiviat et pérenniser le projet.