La solution la plus innovante est parfois la plus simple

« C’est tout ? »

J’aime assez cette réaction.

Une équipe peut avoir passé plusieurs semaines à comprendre un problème, tester différentes pistes, mesurer, faire des prototypes, remettre en cause certaines hypothèses et éliminer progressivement des solutions.

Puis un jour, quelque chose fonctionne.

Et parfois la solution finale paraît presque évidente.

« C’est tout ? »

Oui.

Mais il fallait peut-être traverser toute cette complexité pour comprendre qu’on n’en avait finalement pas besoin.

En R&D, nous avons parfois une relation étrange avec la complexité. Une solution sophistiquée semble naturellement plus innovante. Plus de composants, plus d’algorithmes, plus d’abstraction ou une technologie plus récente donnent facilement l’impression que davantage d’ingénierie a été réalisée.

Pourtant, la complexité d’une solution ne dit rien de la difficulté du problème qui a permis d’y arriver.

Et encore moins de sa qualité.

Simple ne veut pas dire simpliste #

Il y a une différence importante entre simplifier un problème et l’ignorer.

Une solution simpliste écarte une partie des contraintes pour obtenir une réponse facile.

Une solution simple, au contraire, peut être le résultat d’une compréhension suffisamment profonde du problème pour savoir exactement ce qui est nécessaire — et surtout ce qui ne l’est pas.

C’est assez différent.

Si je retire un mécanisme indispensable à la sécurité, à la performance ou à la robustesse d’un produit, je n’ai pas simplifié le système. J’ai simplement déplacé le problème.

Mais si deux architectures répondent aux mêmes contraintes et que l’une nécessite trois composants là où l’autre en nécessite douze, la deuxième n’est pas automatiquement plus innovante parce qu’elle est plus sophistiquée.

Elle est simplement plus complexe.

Et cette complexité devra avoir une raison d’exister.

La complexité doit acheter quelque chose #

Chaque couche technique supplémentaire possède un coût.

Elle devra être développée, testée, documentée, maintenue et comprise.

Elle introduira potentiellement de nouvelles dépendances, de nouveaux modes de défaillance et de nouvelles interactions avec le reste du système.

Cela ne signifie évidemment pas qu’il faut éviter la complexité.

Certains problèmes sont complexes et nécessitent des solutions complexes.

Mais lorsque j’en ajoute, j’aime bien savoir ce qu’elle m’achète.

Une meilleure performance ?

Plus de robustesse ?

Une nouvelle capacité ?

Une réduction du risque ?

Une meilleure maintenabilité ?

Un gain de temps suffisamment important ?

Si je suis incapable de répondre, il est peut-être utile de se demander pourquoi cette complexité est là.

La technologie peut facilement devenir l’objectif #

C’est particulièrement visible lorsque certaines technologies deviennent très attractives.

Aujourd’hui, c’est évidemment le cas de l’intelligence artificielle.

Un problème pourrait être résolu par un algorithme déterministe relativement simple, mais l’utilisation d’un modèle d’IA paraît parfois plus innovante.

Alors on ajoute un modèle.

Puis il faut gérer les données, l’inférence, les performances, les cas limites, le monitoring et tout ce qui accompagne désormais cette décision.

Tout cela peut être parfaitement justifié si l’IA apporte quelque chose que nous n’aurions pas obtenu autrement.

Mais si elle permet simplement d’obtenir, avec davantage de complexité, le même résultat qu’une solution plus simple, où se trouve réellement l’innovation ?

Et l’IA n’est qu’un exemple.

On peut faire exactement la même chose avec une architecture distribuée, des microservices, du cloud, un nouveau framework, un capteur plus sophistiqué ou n’importe quelle technologie suffisamment séduisante pour devenir une solution avant même que le problème soit correctement posé.

Parfois, l’innovation consiste à retirer #

On imagine facilement l’innovation comme une addition.

Ajouter une fonctionnalité.

Ajouter un capteur.

Ajouter un algorithme.

Ajouter une couche logicielle.

Ajouter une nouvelle technologie.

Pourtant, une partie importante du travail d’ingénierie consiste parfois exactement à faire l’inverse.

Retirer un composant devenu inutile.

Supprimer une abstraction qui n’apporte plus rien.

Remplacer plusieurs mécanismes par un seul.

Abandonner une fonctionnalité dont personne n’a réellement besoin.

Réduire le nombre d’états possibles d’un système.

Ou simplement accepter qu’un problème puisse être résolu avec quelque chose que nous connaissons déjà.

La valeur créée n’est alors pas dans ce que nous avons ajouté.

Elle est dans ce que nous avons compris suffisamment bien pour pouvoir enlever.

Une solution évidente peut avoir demandé énormément de travail #

C’est probablement ce qui rend certaines innovations difficiles à valoriser.

Lorsque le résultat est simple, tout le travail qui a permis d’y parvenir disparaît.

On ne voit plus les prototypes abandonnés.

Les mesures qui ont invalidé une hypothèse.

Les architectures qui semblaient prometteuses.

Les semaines passées à comprendre pourquoi quelque chose ne fonctionnait pas.

On ne voit que le résultat final.

Et lorsque celui-ci paraît évident, il est facile de penser qu’il était évident depuis le début.

Il ne l’était généralement pas.

C’est même parfois l’un des signes d’un travail d’ingénierie réussi : la complexité nécessaire pour comprendre le problème n’est plus visible dans la solution qui en résulte.

Je ne cherche pas la solution la plus simple #

Il faut malgré tout se méfier de l’excès inverse.

La simplicité ne doit pas devenir un dogme.

Je ne cherche pas systématiquement la solution la plus simple.

Je cherche plutôt la solution la moins complexe capable de satisfaire correctement le besoin, ses contraintes et le niveau de risque acceptable.

Parfois elle sera extrêmement simple.

Parfois elle nécessitera une architecture complexe, plusieurs disciplines, des algorithmes sophistiqués ou des années de R&D.

Dans ce cas, cette complexité est légitime.

Le travail consiste alors à la maîtriser et, lorsque c’est possible, à éviter de la transmettre à celui qui utilisera le produit.

Un utilisateur ne devrait pas avoir à supporter toute la complexité qui a été nécessaire pour résoudre son problème.

« Pourquoi personne n’avait fait aussi simple avant ? » #

On associe souvent l’innovation à une réaction :

« Comment ont-ils réussi à faire quelque chose d’aussi complexe ? »

Mais il en existe une autre que je trouve au moins aussi intéressante :

« Mais pourquoi personne n’avait fait aussi simple avant ? »

Derrière cette apparente évidence se cache parfois énormément de compréhension, d’essais, d’erreurs et de décisions.

L’innovation n’est donc pas nécessairement la quantité de technologie que l’on réussit à mettre dans un produit.

Elle peut aussi être la quantité de technologie que l’on réussit à ne plus y mettre.

Et c’est probablement une assez bonne manière d’expliquer ce que j’entends lorsque j’écris :

Complexité → Évidence.