DevSecOps : à partir de quand l’automatisation devient rentable

Au début, la règle paraît évidente.

Si une tâche est répétitive, il faut l’automatiser.

C’est un réflexe largement encouragé en DevOps et en DevSecOps. Il est même souvent présenté comme un marqueur de maturité. Pourtant, avec un peu de recul, cette idée montre ses limites.

Certaines automatisations ne font pas gagner de temps.
Certaines deviennent coûteuses à maintenir.
D’autres, plus problématiques encore, masquent des décisions critiques derrière des scripts opaques.

La vraie question n’est donc pas peut-on automatiser ?
Mais plutôt : à partir de quand cela vaut-il vraiment le coup ?

Une manière simple de poser le problème

On peut ramener la décision à une comparaison assez directe.

Le coût d’une tâche réalisée manuellement dans le temps :

Le coût de cette même tâche automatisée :

Avec :

La condition est simple :

Autrement dit, une automatisation n’est pertinente que si elle devient moins coûteuse dans le temps.

Le point de bascule

Prenons un cas très simple.

Une tâche de deux heures, exécutée une fois par mois.
Automatiser cette tâche prend environ dix heures.

Sans automatisation, sur un an, cela représente vingt-quatre heures.
Avec automatisation, on dépense dix heures au départ, puis presque rien.

Le gain existe, mais il est lent. Le point de bascule, le moment où l’automatisation devient rentable, n’arrive qu’après plusieurs mois.

Ce point est souvent invisible dans les décisions du quotidien. On automatise, mais sans se demander quand l’investissement sera amorti.

Ce qui compte vraiment : la fréquence

Intuitivement, on pense que ce sont les tâches longues qu’il faut automatiser.
En pratique, c’est rarement le bon critère.

Une tâche courte mais très fréquente devient rapidement coûteuse.
À l’inverse, une tâche longue mais rare peut rester acceptable.

Ce déplacement de perspective est important :

Ce n’est pas la durée qui détermine la rentabilité, mais le produit durée × fréquence.

Le facteur souvent ignoré : la stabilité

Le modèle précédent suppose une chose implicite : que la tâche ne change pas.

Or, dans un environnement réel, beaucoup de tâches évoluent :

• nouvelles règles de sécurité
• changements d’API
• ajustements métier
• cas particuliers imprévus

Dans ce contexte, il faut introduire un nouveau terme :

                                 

Plus une tâche est instable, plus le coût de maintenance augmente.
Et plus ce coût augmente, plus la rentabilité de l’automatisation diminue.

Une tâche qui change constamment peut ne jamais atteindre son point de rentabilité.

Automatiser une cible mouvante

Automatiser une tâche instable revient à figer quelque chose qui, par nature, ne l’est pas.

On se retrouve alors avec :

• des scripts qui cassent régulièrement
• des correctifs permanents
• une logique difficile à suivre

Le gain initial disparaît, remplacé par une charge de maintenance diffuse.

Dans certains cas, l’automatisation ne simplifie pas le travail. Elle le déplace.

Le risque spécifique au DevSecOps

Dans un contexte DevSecOps, il y a un autre effet, plus subtil.

L’automatisation peut masquer la logique de décision.

Un pipeline peut bloquer ou autoriser un déploiement sans que les raisons soient réellement comprises.
Un outil peut valider une configuration sans que ses limites soient visibles.

On ne perd pas seulement du temps.
On perd de la lisibilité.

Et parfois, on automatise une décision imparfaite, qui se retrouve alors appliquée à grande échelle.

Vers une décision plus nuancée

Avec le recul, quatre critères permettent de mieux cadrer la décision :

• la fréquence
• le coût unitaire de la tâche
• la stabilité dans le temps
• la lisibilité de l’automatisation produite

Une tâche fréquente et stable est une excellente candidate.
Une tâche rare et instable en est une mauvaise.

Entre les deux, il existe une zone grise où l’automatisation partielle, assistance, scripts simples, garde-fous, peut être plus pertinente qu’une automatisation complète.

Ce que cela change concrètement

Ce raisonnement amène à reconsidérer certaines pratiques.

Toutes les tâches répétitives ne doivent pas être automatisées immédiatement.
Certaines doivent rester manuelles, au moins temporairement.
D’autres doivent être observées avant d’être industrialisées.

L’automatisation devient alors une décision progressive, et non un réflexe.

Conclusion

L’automatisation n’est pas un gain instantané.
C’est un investissement, avec un coût initial, une incertitude, et un horizon de rentabilité.

Chercher à tout automatiser revient à ignorer cette réalité.

En DevSecOps, la maturité ne consiste pas à automatiser le plus possible, mais à automatiser au bon moment, au bon endroit, et pour les bonnes raisons.

Et parfois, la meilleure décision reste encore de ne pas automatiser.