Efficacité vs Efficience : tu préfères manquer d'air ou d'eau ?

Toute organisation qui veut survivre doit évoluer, changer, s’améliorer. Sinon ? Elle crève.

Mais ça veut dire quoi, “s’améliorer”, d’un point de vue systémique ? C’est assez simple :

• Soit on augmente le rendement : à quelle vitesse on produit → efficience
• Soit on augmente le résultat : à quelle vitesse on atteint un objectif → efficacité

On a tendance à confondre les deux. Parfois, ça revient au même. Mais souvent, c’est deux choses très différentes. Et à force de pas faire la différence, on se plante. Comme des cons.

Lexique

Commençons par définir quelques termes qu’on va utiliser tout du long, et qui pourraient ếtre ambigues. C’est là mes définitions et si elles vous déplaisent, cassez-vous je suis pas là pour discuter lexique.

• Temps de cycle: intervalle de temps compris entre la production de deux produits. Appliqué à l’informatique, c’est temps que met un programmeur à finir la tâche, avant de passer à la suivante.

C’est quoi le problème ?

Une startup, c’est pas un marathon. Je dirai que c’est tout sauf un marathon. C’est une putain de course d’orientation en pleine forêt, sans sentier, et avec une carte qui change toutes les 15 minutes.

Du coup : Tu préfères courir plus vite sans regarder la carte, ou ralentir pour checker la direction souvent ? Et maintenant imagine qu’une voiture-balai part 30 minutes après tout le monde. Si elle te rattrape, t’es disqualifié.

Toujours la même réponse ? C’est ça le contexte d’une Startup.

Efficience

L’efficience dans notre exemple, c’est courir plus vite.

Au début, tous les fondateurs se confrontent au monde. Ils analysent la carte et se font une idée du meilleur chemin. Et s’ils se plantent, ils dégagent. Rapide.

Mais si tu passes ce premier cap, va falloir bosser ton efficience. Sinon tu vas quand même dégager. Bonne nouvelle : l’efficience, au début, c’est simple. Quelques process, des outils de suivi, deux-trois rituels. PAF, ça fait des chocapics.

Comment on réduit le nombre de bugs ? Comment on diminue notre temps de cycle ? Comment on delivre plus souvent ? Toutes les industries sont au taquet là-dessus. Tu deviens prévisible, tu poses des KPI, tu traques les tendances.

Mais attention : l’amélioration ici suit une courbe logarithmique. Tu gagnes beaucoup au début, puis ça devient galère.

Et surtout : si tu ne fais QUE ça, tu meurs le jour où la ligne d’arrivée bouge.

Tu penses que Blockbuster, Canon ou Toys“R”Us étaient inefficients ? Sérieux ?

Efficacité

T’es toujours en course. Mais la carte a changé. Et elle va continuer à changer.

Si toutes les initiatives produit viennent des fondateurs, t’as un problème qui arrive à toute vitesse. T’as sûrement déjà entendu, voire dit : “Mais on connaît le client ! Il VEUT cette feature !” Ouais, comme un politicien qui dit : “Moi je connais la vraie vie.” C’est peut-être pas faux. Mais c’est clairement pas une preuve.

Et maintenant ? Maintenant, ce qui t’a fait arriver là, va te planter. Livrer plus vite ne suffit plus. Il faut livrer de la valeur. De la vraie. Pas celle que les fondateurs imaginent. Celle que seuls les comportements clients peuvent valider.

Alors pose-toi les bonnes questions : Comment on sait qu’une feature a vraiment apporté de la valeur ? C’est quoi “la valeur” ? Est-ce que le temps passé sur cette initiative a rapporté plus qu’il a coûté ? Comment on priorise les bonnes features, sans piloter au doigt mouillé ?

Tu préfères manquer d’air ou d’eau ?

Un pote US me disait souvent : “Sans air, tu survis 3 minutes. Sans eau, 3 jours.”

Donc ouais, l’un est plus urgent, mais si tu règles pas les deux, t’es mort.

Pas d’efficience ? Tu vas crever. Vite. Ton équipe aussi. Tout sera lourd, lent, pénible. Livrer devient une épreuve olympique. Modifier du code, c’est désamorcer une bombe. Tu crois survivre longtemps comme ça ? Non. Tu finiras dans le cimetière des boîtes “qui avaient une super idée mais…”

Pas d’efficacité ? Tu vas péricliter. Doucement, mais sûrement. Tu vas répéter “on va pas assez vite” en boucle, commencer à fliquer les devs, voir ton turnover grimper, et en France, t’auras un désengagement passif généralisé.

Du coup, l’air ou l’eau? En vrai, si tu t’assures pas d’avoir les deux… tu crèves. Lentement ou rapidement, mais tu crèves quand même.

OK, mais on fait quoi ?

Déjà, on arrête de confondre les deux mots. Les mots comptent. Ce qui vous tue le plus sûrement, c’est ce que vous ignorez ignorer.

Côté efficience : Mettez en place des méthodes, outils, rituels, et KPI (temps à livrer, nombre de bug post livraison sur le périmètre, temps de cycle, complaintes principales des équipes tech). Vous allez voir une amélioration rapide. Puis une stagnation. C’est normal.

Ce qui compte, ce sont les tendances longues. Une ou deux semaines de délai ? OK. Des mois de détérioration continue ? Là, il faut agir.

Côté efficacité : Comment validez-vous qu’une feature a vraiment apporté de la valeur ? Comment vous savez que la feature A méritait plus que la B ? Et si vous pouvez pas répondre à ça… comment osez-vous dire que vos choix étaient bons ?

Une montée des ventes peut venir de plein d’autres facteurs : meilleure météo, marketing, chance… Pas forcément vos nouvelles features.

💡 Note : On ne peut jamais prouver qu’une hypothèse est vraie. Mais on peut prouver qu’elle est fausse. Pour approcher la vérité, commencez par éliminer le faux.