Le vrai coût d’un mauvais workflow CI : la charge cognitive

Un pipeline CI rapide ne suffit pas si le workflow de développement est différent du workflow de build. Cet article explore le coût humain et organisationnel d’un mauvais alignement entre local et CI, et pourquoi le principe d’un seul point d’entrée est non négociable.

I. Le vrai coût d’un mauvais workflow CI : la charge cognitive  

On parle beaucoup de performance des pipelines CI.
On mesure les minutes.
On optimise les caches.
On parallélise.

Mais le vrai coût d’un mauvais workflow CI n’est pas le temps machine.

C’est la charge cognitive.

Et elle est beaucoup plus chère.

II. Le problème invisible  

Un pipeline CI inefficace est visible :

• builds longs
• jobs qui timeout
• ressources gaspillées

Un pipeline mal aligné avec le développement, lui, est beaucoup plus insidieux :

• les développeurs ne comprennent plus ce qui s’exécute
• la CI devient une boîte noire
• on multiplie les scripts “temporaires”
• les erreurs deviennent imprévisibles

Ce n’est plus un problème technique.
C’est un problème organisationnel.

III. Deux systèmes, deux échecs probables  

Le pattern le plus dangereux est simple :

• un système pour développer en local
• un autre système pour builder en CI

En local :

• pnpm dev
• go run
• forge test
• scripts artisanaux

En CI :

• YAML complexe
• commandes différentes
• conditions spécifiques
• variables implicites

Résultat :

• ce qui marche en local ne marche pas en CI
• la CI corrige des choses que les développeurs ne voient jamais
• personne ne maintient les deux systèmes proprement

Deux systèmes signifient toujours qu’un des deux est négligé.
Et souvent… les deux.

IV. Le désalignement local / CI : une dette qui ralentit l’équipe  

Quand le flux de développement est différent du flux de build :

• les développeurs optimisent leur confort local
• la CI optimise la robustesse et la reproductibilité
• les deux divergent progressivement

On observe alors :

• duplication de logique
• règles implicites
• scripts de contournement
• “ça marche chez moi”
• frustration croissante

Cette divergence crée une dette organisationnelle :

• plus personne ne comprend vraiment le pipeline
• chaque modification devient risquée
• le système devient fragile

La performance du pipeline peut être excellente.
Mais la compréhension collective est mauvaise.

Et c’est cela qui ralentit une équipe.

V. La charge cognitive comme indicateur principal  

Un workflow CI sain devrait avoir une propriété simple :

Un développeur doit pouvoir expliquer le pipeline sans ouvrir la configuration CI.

Si ce n’est pas le cas :

• trop de logique est cachée
• trop de règles sont implicites
• trop d’étapes ne sont pas exécutables localement

La charge cognitive augmente quand :

• il faut se souvenir de règles non écrites
• il existe des exceptions partout
• les comportements changent selon l’environnement

VI. L’erreur classique : optimiser la machine, pas le système humain  

Beaucoup d’équipes investissent massivement dans :

• du caching avancé
• des runners distribués
• du multi-stage Docker optimisé
• du parallélisme

Mais oublient la question centrale :

Est-ce que le workflow local et le workflow CI sont identiques ?

Un pipeline peut être très rapide…
et pourtant être un cauchemar mental.

VII. Le principe non négociable : un seul point d’entrée  

La solution est simple à formuler, difficile à respecter :

Un seul point d’entrée pour exécuter le travail.

Cela signifie :

• Les mêmes commandes en local et en CI
• La même logique d’orchestration
• Le même graphe de dépendances
• Les mêmes règles d’invalidation

Concrètement :

• si on utilise nx build en CI
  → on utilise nx build en local
• si un test est exécuté en CI
  → il est exécutable localement avec la même commande
• si un projet est “affected” en CI
  → la même logique s’applique en local

Quand ce principe est respecté :

• la CI cesse d’être une boîte noire
• les développeurs gagnent en autonomie
• les bugs liés à l’environnement disparaissent
• la maintenance devient naturelle

VIII. Pourquoi ce sujet est rarement traité  

Parce que :

• la performance est mesurable
• la charge cognitive ne l’est pas
• les outils vendent des gains techniques
• peu parlent d’alignement organisationnel

Et pourtant, dans les petites équipes en particulier,
la compréhension partagée est un multiplicateur bien plus puissant que l’optimisation brute.

IX. Le vrai signal d’alerte  

Si vous entendez souvent :

• “la CI fait des trucs bizarres”
• “je ne sais pas pourquoi ça rebuild”
• “ne touche pas à ce fichier sinon ça casse”
• “on verra en CI”

Alors le problème n’est pas technique.
Il est structurel.

Conclusion  

Un mauvais workflow CI ne coûte pas seulement :

• du temps machine
• de l’argent
• des ressources

Il coûte :

• de la clarté
• de la confiance
• de la vitesse collective

Deux systèmes = aucun système maintenu correctement.
Dev flow ≠ build flow = dette organisationnelle.

Le principe simple à retenir :

Un seul point d’entrée. Une seule logique. Une seule source de vérité.

La performance vient ensuite.

🔗 Liens utiles  

• Dave Farley — Continuous Delivery principles

• Nicole Forsgren et al. — Accelerate: The Science of Lean Software and DevOps