Principe de mesure

ImpactGate attribue à chaque modification un impact calculé par la formule : impact = files_changed × Σ max(WMC_other,1) × CC × Δlines. WMC_other représente la complexité (Weighted Methods per Class) du conteneur modifié avant le commit, CC le cyclomatic complexity du ou des fonctions concernées, et Δlines le nombre de lignes ajoutées ou supprimées. Le produit files_changed × Σ … amplifie les changements qui touchent plusieurs fichiers lourds, ce qui signale une decay potentielle du code.

Le modèle privilégie les ajouts de nouveaux fichiers ou classes (WMC_other = 0 → max(0,1)=1) comme peu coûteux, tandis que l’enrichissement d’une classe déjà complexe augmente linéairement le score. Cette approche repose sur l’hypothèse que la complexité existante est le principal facteur de risque de détérioration.

Intégration et modes d’usage

Le projet propose trois points d’entrée : une interface en ligne de commande, un hook pre‑commit, et des plugins pour GitHub, GitLab ou Jenkins. L’installation se fait via 

pip install impact-gate
ou par l’image Docker officielle : 
docker run --rm -v "$PWD:/repo" ghcr.io/officefloor/impact-gate score \
  --mode range --base origin/main
Le mode range compare la branche courante à la base (par défaut origin/main), tandis que worktree analyse les modifications non committées. Les seuils d’avertissement (--warn-at) et de blocage (--block-at) sont paramétrables ; la sortie d’état 0 indique un impact acceptable, 2 signale un blocage, 1 indique une erreur d’usage.

En mode pré‑commit, la commande impact-gate install-hook crée le script .git/hooks/pre-commit. Si le score dépasse le seuil de blocage, le commit est interrompu, ce qui empêche la propagation de la dette technique dans la branche principale.

Analyse des limites et des risques

Le calcul dépend fortement de la précision des métriques WMC et CC, qui varient selon le langage et les outils d’analyse statique sous‑jacents. Aucun détail n’est fourni sur la prise en charge de langages spécifiques, ce qui peut entraîner des scores incohérents entre projets Java, Python ou JavaScript. De plus, la formule agrège les facteurs par multiplication, supposant une corrélation linéaire qui n’est pas toujours vérifiable : une hausse de Δlines dans un fichier déjà lourd peut être compensée par une refactorisation, mais le score restera élevé.

Le paramètre max_diff_lines (200 000 lignes par défaut) exclut les gros fichiers générés, évitant ainsi des valeurs aberrantes. Cependant, la valeur fixe peut masquer des ajouts légitimes dans de très grands projets, nécessitant une adaptation manuelle.

Évolution et perspectives d’usage

Pour atténuer la difficulté de choisir un seuil absolu, ImpactGate propose un mode de notation percentile (--curve). Après génération d’une distribution de référence via 

impact-gate baseline --base-ref main
, le score d’une modification est exprimé en percentile, permettant de fixer des seuils de 90 % (avertissement) et 98 % (blocage). Cette méthode s’ajuste automatiquement aux variations de taille et de complexité propres à chaque dépôt.

En résumé, ImpactGate fournit un cadre quantitatif pour détecter la « décadence structurelle » lors des revues de code, tout en restant sensible aux paramètres de projet. Son efficacité repose sur la qualité des métriques d’analyse et sur une calibration adaptée aux spécificités du code étudié.