Une boucle de rétroaction qui reviendra relativement pas cher

Mon éditorial

Dans ma mise à jour du 31 Janvier (consultez « Smart cities, or rummaging in the waste heap of culture ») j’ai avancé un peu avec ce business plan pour investir dans les villes intelligentes. Voilà que je construis mon business plan autour de quatre hypothèses de travail. Un, une ville intelligente va avoir besoin de plus de masse monétaire pour financer son fonctionnement qu’une ville « ordinaire », afin de pourvoir à l’incertitude découlant d’une dépréciation accélérée des technologies installées sur place. Deux, la construction et la mise à jour de l’infrastructure d’une ville intelligente va s’associer, au moins périodiquement, à une consommation plus élevée d’énergie par tête d’habitant et ceci, encore une fois, dû à la nécessité de remplacement fréquent des technologies à cycle de vie très court. Trois, le développement des villes intelligentes va entraîner une accumulation des populations locales autour de sources d’énergie. Quatre, dû à la présence de plus de masse monétaire par unité de produit réel, les villes intelligentes vont engendrer des structures sociales plus hiérarchisées que les villes « ordinaires », avec une distance croissante entre la base et le sommet de la pyramide sociale.

Deux remarques s’imposent. Premièrement, pourquoi diable formuler des hypothèses pour construire un business plan ? Après tout, c’est du business, pas de la science, et je pourrais bien être en train de confondre les genres. Ma philosophie est simple sur ce point-là : tout business plan digne de ce nom devrait contenir une analyse poussée de l’environnement et l’analyse en question ne peut que gagner en valeur si on formule des hypothèses bien ciblées. En plus, tout investissement qui implique une course technologique rapide implique aussi beaucoup d’incertitude, que je peux réduire en formulant des scénarios alternatifs d’évènements. Les hypothèses, ça tombe bien lorsque je veux des scénarios : le scenario A implique la véracité desdites hypothèses pendant que le scenario B assume qu’elles sont fausses.

Deuxièmement, je me casse la tête comment appeler des structures urbaines qui ne sont pas des villes intelligentes. Par pure opposition, je pourrais me référer à des villes « bêtes », encore que ça pourrait sonner bête en soi-même. Pour le moment j’utilise donc le terme de ville « ordinaire » mais je serais reconnaissant pour toute suggestion linguistique à ce sujet.

Bon, j’en viens à l’essentiel de cette mise à jour : comment pouvons-nous expérimenter avec les technologies qui font l’ossature d’une ville intelligente ? C’est une question pratique. Si je veux convaincre une entreprise d’investir dans un projet de ville intelligente, c’est un investissement en technologie, qui, à son tour, se caractérise par un certain cycle de vie. C’est une composante tout à fait élémentaire de stratégie pour quiconque s’engage dans un projet à haute cadence d’innovation : si aujourd’hui j’investis 5 millions d’euros dans une technologie de transport urbain intelligent, quand est-ce que viendra le moment de la remplacer et comment dois-je diriger ma recherche pour être prêt à temps avec la nouvelle version ? Si je veux convaincre quelqu’un d’investir dans un tel projet, un sentier d’expérimentation pour développer ces technologies serait certainement attractif.

Une expérience scientifique est un modèle réduit de réalité où je teste des hypothèses que je ne peux pas tester autrement. D’habitude ce sont des hypothèses quant au déroulement exact d’une séquence d’évènements. Ces hypothèses-là sont comme des zooms sur des fragments d’hypothèses générales d’un projet de recherche. Ce que j’essaie de faire, en ce moment précis, consiste à traduire mes hypothèses générales en des lignes d’expérimentation et, en parallèle – à trouver une application pratique de ces expériences pour le développement des technologies de ville intelligente. Ma première hypothèse générale dit que le développement d’une ville intelligente va créer une demande accrue de masse monétaire. J’ai deux associations d’idées, immédiates et pratiques. D’abord, le FinTech : cette hypothèse générale se traduit, au niveau business, comme l’assertion que les projets FinTech vont se développer plus rapidement dans le cadre des villes intelligentes qu’ailleurs. Ensuite, le bilan : la seconde traduction pratique suppose que les entreprises engagées dans les projets de ville intelligente auront des actifs significativement plus liquides que les entreprises qui restent en dehors de tels projets, autres facteurs tenus constants.

Si je m’engage dans cette ligne d’expérimentation, il serait bon d’avoir un modèle réduit de transactions financières qui ont lieu dans un environnement de ville intelligente. J’imagine des environnements sociaux différents : un environnement urbain avec beaucoup de technologies digitales connectées au fonctionnement d’infrastructure urbaine, puis un environnement toujours grand-urbain mais nettement mois infus des solutions type « smart city », et à côté de ces deux un environnement typiquement provincial, par exemple celui d’une petite ville. Dans chacun de ces environnements j’observe le développement des micromarchés locaux de Fintech ainsi que les bilans des entreprises actives dans les mêmes marchés locaux. Question : quelle serait la différence entre l’environnement expérimental d’une part et une simple observation de marché d’autre part ? Je veux dire qu’à la rigueur je peux observer la demande pour des services FinTech à travers cet outil appelé « moteur comportemental » – ou « behavioural engine » en anglais – qui observe le comportement d’utilisateurs d’Internet. De même, simple audit comptable périodique peut me donner des informations requises au sujet des bilans. Dans les deux cas, il n’y a pas de besoin impératif de mettre au point une ligne d’expérimentation.

La différence entre une expérience scientifique et la simple observation peut être de double nature. Premièrement, une expérience peut être plus efficace que l’observation dans la mesure où elle fournit des informations plus rapidement et/ou à moindre coût. Une expérience peut donc être un raccourci précieux par rapport à la vie réelle. Deuxièmement, une expérience peut me permettre d’imposer à mon objet expérimental des conditions plus extrêmes que celles de la vie réelle. Côté efficacité, une expérience au sujet de demande pour des services FinTech pourrait se concentrer sur le mécanisme de choix de la part des consommateurs lorsqu’ils sont confrontés à un moment de décision. Une autre idée est le type d’expérience bien connue, par ailleurs, dans le monde des technologies digitales : confronter un groupe d’utilisateurs avec un groupe d’ingénieurs. Les utilisateurs imposent aux ingénieurs un effort constant d’innovation en effectuant des choix en séquence. Chaque choix fait par chacun des utilisateurs est une pièce d’information pour chacun des ingénieurs. Un ingénieur donné réagit au flux d’information par un flux de travail qui résulte en un choix nouveau présenté aux utilisateurs. Leurs choix individuels se somment en un flux nouveau d’information pour les ingénieurs etc.

Disons qu’un groupe de 100 personnes est confronté avec une situation où ils ont une somme de €1000 à allouer parmi des types d’épargne et/ou investissement plus, par exemple, une option d’acheter à l’avance, à un prix attractif, un voyage de vacances ou un paquet des billets de théâtre. Les consommateurs font leur choix – ils allouent leurs €1000 respectifs parmi les options accessibles – et maintenant les ingénieurs ont pour tâche de mettre au point et proposer à chacun des consommateurs une utilité digitale FinTech la mieux adaptée possible aux besoins déduits des choix antérieurs. Chaque ingénieur propose aux consommateurs sa solution originale et chaque consommateur choisit – entre toutes les solutions présentées – celle ou celles qui lui va (vont) le mieux. Ensuite, ou bien en parallèle, nous observons la façon dont les consommateurs utilisent les solutions proposées : le temps passé en face de l’écran, nombre des clicks, séquence d’actions, nombre des pas ratés suivis des pas en arrière etc. Les ingénieurs ont la possibilité d’observer le comportement des consommateurs ou bien reçoivent des rapports là-dessus. Leur tâche consiste alors à optimiser les solutions sélectionnées et de présenter aux consommateurs des prototypes optimisés de seconde génération et ainsi de suite. Bien sûr, au lieu de mettre en compétition des ingénieurs individuels on peut établir des groupes de travail rivaux.

Ce type d’expérience est, pour autant que je sache, pratiqué souvent dans l’industrie informatique. L’idée originale consiste, cette fois, à ajouter un méta niveau d’expérimentation : observer et documenter l’interaction entre les consommateurs et les ingénieurs pour tirer des conclusions sur le processus-même d’innovation. Une expérience comme celle-là serait une version accélérée d’un marché. L’interaction entre les utilisateurs et les ingénieurs, qui dans les conditions d’un marché réel des produits digitaux peut se dérouler sur des années est accélérée et prend, par exemple, des semaines. La différence pratique entre l’environnement expérimental et le monde réel consiste dans l’absence des barrières dans l’échange d’information, habituellement rencontrés dans la pratique du marché. Si je suis un expérimentateur vraiment tenace (vraiment vache ?), je peux simuler ce qui se passe si j’ajoute ces barrières dans le processus. Je peux, par exemple, ajouter un rapporteur intermédiaire entre les consommateurs et les ingénieurs et tester l’impact de sa présence sur le déroulement du processus d’innovation. Ce rapporteur ne doit même pas être un humain : ça peut être un logiciel qui filtre les informations d’une manière biaisée. Avec un peu d’astuce, je peux utiliser cette expérience pour optimiser des structures sociales pour innovation.

Quand j’y pense, cette philosophie d’expérimentation peut être appliquée partout dans l’informatique et pas seulement dans le FinTech. La question essentielle à laquelle répond ce type d’expérimentation est « Combien de temps avons-nous réellement besoin pour mettre au point des solutions nouvelles et comment ce temps peut être modifié par la présence ou l’absence des facteurs de distorsion ? » Zut, je commence à voir plus large. Ça peut faire presque mal, parfois. Je peux utiliser ce cadre d’expérimentation pour toute technologie où, premièrement, il est possible de mettre les utilisateurs et les ingénieurs en boucle de rétroaction, et deuxièmement, où ladite boucle reviendra relativement pas cher.

Ceux parmi vous qui ont bien voulu suivre mon activité de blogger sur l’année dernière ont probablement vu que mon objectif est de créer de la science de bonne qualité, neuve ou presque. Sur mon chemin vers la création d’un site éducatif payant je passe par le stade de financement participatif. Voici le lien hypertexte de mon compte sur Patreon . Si vous vous sentez prêt à cofinancer mon projet, vous pouvez vous enregistrer comme mon patron. Si vous en faites ainsi, je vous serai reconnaissant pour m’indiquer deux trucs importants : quel genre de récompense attendez-vous en échange du patronage et quelles étapes souhaitiez-vous voir dans mon projet de création de site éducatif ?