Calculateur de rentabilité d’une automatisation

Le travail aujourd’hui

Toutes celles qui y passent du temps, pas une seule équipe.

Le temps passé sur cette tâche seule.

Salaire et charges patronales comprises.

Ce que coûterait le projet

Soyez pessimiste. Rarement plus de 50 %.

Construction, intégration et déploiement réunis.

Licences, hébergement, maintenance.

Heures libérées par an

1 175

Valeur, coût de fonctionnement déduit

58 500 €

Remboursé en

12,3 mois

Heures libérées
10 personnes × 5 h × 47 semaines × 50 % = 1 175 h
Valeur de ces heures
1 175 h × 60 € = 70 500 €
Première année, tout déduit
70 500 € − 12 000 € − 60 000 € = -1 500 €

Ceci est une estimation, ni une prévision ni une promesse. C’est la multiplication de vos propres hypothèses, affichée étape par étape pour que vous puissiez contester chacune d’elles. Le chiffre qui est faux est presque toujours la part automatisable : mesurez-la sur un échantillon de cas réels avant d’accorder du crédit au reste.

Cet outil multiplie six nombres que vous fournissez et affiche chaque étape du calcul, ce qui constitue l’intégralité de ce qu’il fait. Il ne connaît pas votre secteur, il ne contient aucune donnée de comparaison, et il repose sur une seule constante : une année de travail de 47 semaines, soit 52 moins cinq pour les congés et les jours fériés. Retenir 52 gonflerait chaque résultat d’environ un dixième, et c’est la raison pour laquelle ce chiffre est écrit ici plutôt qu’enfoui dans le code. Le résultat n’est ni une prévision ni une promesse. C’est la conséquence de vos propres hypothèses, exposée de façon à ce que vous puissiez contester chacune séparément au lieu de contester un total. Si le résultat vous surprend, l’entrée à réexaminer n’est presque jamais le coût horaire. C’est la part du travail que vous croyez automatisable, qui est le nombre dont on est le plus sûr et celui dont on se trompe le plus souvent.

Estimer correctement la part automatisable

Toutes les autres entrées de cette page sont connues ou connaissables. Le nombre de personnes est un fait. Le coût horaire figure dans un logiciel de paie. Le coût du projet est un devis. La part automatisable est un jugement, elle domine le résultat, et elle est couramment surestimée d’un facteur deux.

La raison en est une erreur précise et compréhensible. Quand on se représente une tâche, on se représente le cas standard, parce que c’est lui qui vient à l’esprit. Le cas standard est généralement automatisable. Ce qui consomme le temps, ce sont les exceptions, et les exceptions sont exactement ce qui ne vient pas à l’esprit au moment où l’on vous demande une estimation.

La correction prend une heure et vaut davantage que n’importe quel raffinement de ce modèle. Prenez vingt dossiers réels du mois dernier, tirés au hasard plutôt que choisis. Pour chacun, décidez si le système l’aurait traité de bout en bout sans qu’une personne vérifie la sortie. Comptez. Cette proportion est votre part automatisable, et elle se situe généralement entre un cinquième et la moitié là où la première estimation disait trois quarts.

Ce que ce calculateur laisse volontairement de côté

Le risque d’adoption. La plus grande omission. Un système qui fonctionne correctement et que personne n’utilise ne rapporte rien tout en continuant de coûter son abonnement. Le calculateur ne voit pas ce risque, ce qui signifie que le résultat doit se lire comme le plafond de ce qui est atteignable si l’adoption réussit, et non comme une espérance.

Les heures libérées qui ne se transforment pas en argent. Libérer 1 200 heures sur dix personnes ne réduit aucune masse salariale. Cela rend à dix personnes environ deux heures et demie par semaine, et que cela devienne de la valeur dépend entièrement de ce qu’elles en font. Les organisations qui ont décidé à l’avance à quoi servira le temps libéré en tirent le bénéfice. Les autres constatent un an plus tard que le temps a été absorbé.

Les changements de qualité, dans les deux sens. L’automatisation améliore parfois les résultats d’une façon qui vaut plus cher que le temps gagné, et les dégrade parfois d’une façon qui coûte davantage. Les deux effets sont réels et aucun n’est estimable à l’avance sans mesure, de sorte que leur attribuer un chiffre ici reviendrait à l’inventer.

L’économie de la deuxième année. Le modèle affiche la première année. À partir de la deuxième, le coût de projet a disparu et seul le coût récurrent demeure, si bien qu’un projet qui paraît limite la première année est souvent nettement rentable sur trois. Le délai de remboursement le capture, mais pas le total de la première année, et ne lire que ce total sous-estime la plupart des projets réels.

Lire le résultat honnêtement

Un remboursement en moins de douze mois signifie que le projet se défend sur le seul argument du coût, et la décision se déplace vers la question de savoir s’il peut effectivement être livré. Un remboursement compris entre un et trois ans signifie que le projet doit se justifier sur autre chose que l’arithmétique, ce qui est légitime : la qualité, la réduction d’un risque, ou une capacité que l’organisation veut construire. Un remboursement qui n’arrive jamais signifie que le coût récurrent dépasse la valeur, et aucune qualité d’exécution ne corrige cela.

Le cas sur lequel il vaut la peine de s’arrêter est un remboursement en cinq mois environ sur un premier projet. Ce résultat provient presque toujours d’une part automatisable qui n’a pas été mesurée. La mesurer, par la méthode des vingt dossiers décrite plus haut, est un meilleur usage d’une heure que n’importe quel travail supplémentaire sur le modèle.

Ce que nous en faisons

Nous avons mis cet outil sur le site parce qu’il correspond à la première conversation que nous avons avec la plupart des entreprises, et parce qu’il est assez court pour être tenu honnêtement. Beaucoup de projets d’automatisation méritent d’être menés et une minorité non négligeable ne les mérite pas, et le second groupe est plus facile à repérer avant la construction qu’après.

Si l’arithmétique dit ici qu’un projet n’en vaut pas la peine, c’est une réponse utile et nous préférons que vous la teniez d’un calculateur plutôt que de nous après six semaines. Si elle dit l’inverse, la question suivante n’est pas de savoir combien cela vaut mais si cela peut être livré à l’intérieur de votre organisation, ce qui est une autre question, et c’est celle dont notre métier traite réellement.

Les questions qu’on pose vraiment

Pourquoi six entrées seulement, quand d’autres en demandent vingt ?

Parce que l’incertitude se multiplie. Un modèle à vingt entrées produit un résultat qui paraît plus précis et qui est moins fiable, chaque hypothèse supplémentaire élargissant la fourchette sans que personne ne s’en aperçoive. Ces six entrées sont des choses que vous connaissez ou que vous pouvez estimer honnêtement, et l’arithmétique qui les relie est visible sur la page.

Quelle entrée a le plus de chances d’être fausse ?

La part automatisable, très largement, et c’est celle dont les gens sont le plus sûrs. Le moyen fiable de la corriger est de prendre vingt dossiers réels du mois dernier et de compter combien le système aurait traités de bout en bout, sans qu’une personne vérifie le résultat. Ce nombre est presque toujours très inférieur à la première estimation.

Pourquoi 47 semaines travaillées et non 52 ?

Parce qu’une personne ne travaille pas 52 semaines. Cinq semaines de congés et de jours fériés constituent une moyenne raisonnable sur la plupart des marchés, et retenir 52 gonfle chaque résultat d’environ un dixième. La constante est écrite ici plutôt qu’enfouie dans le code, pour que vous puissiez la contester en connaissance de cause.

Le calcul intègre-t-il le risque que personne n’adopte l’outil ?

Non, et c’est le plus gros absent. Un système qui fonctionne et que personne n’utilise ne rapporte rien tout en continuant de coûter son abonnement, et le calculateur ne voit pas ce risque. Lisez donc le résultat comme le plafond de ce qui est atteignable si l’adoption réussit, et non comme une espérance de gain.

À lire ensuite

Sources

Radif Partners

Écrit et tenu à jour par Radif Partners

Déploiement d’IA appliquée · Ingénierie déployée chez le client

Couvre 2026, · dernière relecture 2026-09-24