Mon éditorial sur You Tube

Voilà un truc intéressant, apparu un peu par accident. Mon université s’engage dans un projet commun avec une société informatique. Le but est de préparer le lancement d’une fonctionnalité digitale du type « App Builder » et le rôle de l’université est de conduire une recherche côté humain, donc d’identifier les facteurs comportementaux significatifs chez les utilisateurs potentiels de cette technologie ainsi que de prédire l’attitude desdits utilisateurs vis à vis du produit, une fois celui mis en marché. Je suis chargé de préparer un plan de recherche et je besoin de déconstruire l’idée générale à fond. Je sais par expérience que le fait de développer un sujet par écrit, sur mon blog, m’aide beaucoup à clarifier mes idées sur un sujet complexe. D’autre part, le sujet en proche de ma propre ligne de recherche que je conduis depuis des années : l’innovation et son contexte social.

Une fonctionnalité du type « App Builder » est un outil informatique qui rend possible la construction rapide d’un logiciel par des personnes qui ne sont pas ingénieurs en technologies digitales. C’est un peu comme un kit de construction type mécano : vous avez une interface principalement visuelle, qui rend possible la construction d’un logiciel à partir des composantes standardisées. Vous avez des fragments substantiels de code informatique accessibles et maniables en la forme des « pièces » visuelles sur l’écran. Vous avec, par exemple, une pièce appelée « Formulaire de contact pour l’utilisateur », une autre décrite comme « Localisation par GPS » et ainsi de suite. Vous les combinez sur votre écran et de cette façon vous construisez le code complet d’un logiciel.

Comme vous pouvez le deviner aisément, cette technologie qui sert à fabriquer d’autres technologies, d’une manière quasi-artisanale, a deux groupes d’utilisateurs : ceux qui utilisent l’AppBuilder directement, pour fabriquer des logiciels – appelons-les « utilisateurs primaires » – et ensuite ceux qui utilisent les logiciels ainsi crées, donc les « utilisateurs secondaires ». Les utilisateurs primaires sont surtout des PME, ainsi que des ONG (Organisations Non Gouvernementale) de taille pas-encore-très-respectable. La logique de leur adhésion à ce produit est basée sur le mécanisme déjà connu depuis des décennies dans le marché des vêtements pour homme. Un costume pour homme, c’est en principe une pièce de vêtement qui se faisait sur mesure. Lorsque le prêt à porter est apparu, la différence sautait – et saute toujours – aux yeux, surtout dans le cas des messieurs qui ne sont pas exactement bâtis comme Tarzan. C’est ainsi que les tailleurs ont inventé un type de couture que les Anglo-Saxons appellent « bespoke » et pour laquelle je n’ai pas trouvé de traduction exacte en français. Le bespoke c’est comme du semi-sur-mesure. Le costume est pré-taillé et sa structure contient des petites pièces astucieusement masquées dans les endroits critiques, comme la ceinture, les hanches ou les épaules. Ces petites pièces rendent possible un ajustement poussé à la silhouette d’un personne précise. Le tailleur prend la mesure du client et ajuste le vêtement à sa silhouette. Le tout est beaucoup moins coûteux et plus rapide que du sur mesure strictement dit, tout en gardant l’élégance dure à trouver dans du prêt-à-porter typique.

Un AppBuilder c’est du digital façon bespoke. Il y en a déjà pas mal d’AppBuilders offerts sur le marché et ils présentent des régularités intéressantes. Premièrement, la majorité d’entre eux est accessible aux utilisateurs primaires sur la base d’un abonnement mensuel et cependant il en reste une minorité qui n’affiche pas du tout de conditions standardisées d’utilisation et qui présentent la collaboration avec chaque utilisateur primaire comme un projet singulier avec des modalités business tout aussi singulières. Deuxièmement, certains de parmi ces AppBuilders – je ne saurais pas dire si c’est une majorité ou bien une minorité – offrent des versions gratuites de base. Nous avons donc une proportion solide du type « majorité – minorité des cas » accompagnée d’un phénomène apparemment aléatoire dans sa manifestation.

L’abonnement mensuel suggère un lien durable entre l’utilisateur primaire d’un AppBuilder et son fournisseur. C’est logique : une fois que j’ai construit un logiciel mobile pour les clients de ma PME, j’aurais besoin de le parfaire et transformer à mesure que d’autres logiciels de même type apparaîtront sur le marché. L’expression « à mesure que » est importante. Le type d’innovation dont je vais avoir besoin dans ce logiciel c’est du progressif, à petits pas, difficiles à planifier en avance. La boîte à outils que j’avais utilisé la première fois doit donc être à portée de la main et en plus les outils dans la boîte feraient mieux de s’adapter aux nouvelles exigences du marché. Le fournisseur de l’utilité AppBuilder garantit donc à son utilisateur primaire l’accès à la boîte digitale à outils ainsi que leur mise à jour régulière.

Ce type de relation « client – fournisseur » implique que la capacité d’innovation digitale de la part du client reste plus ou moins constante. L’utilisateur primaire d’un AppBuilder de ce type développe l’habitude d’utiliser la boîte à outils fournie, sans modifier sa propre capacité d’innovation. En revanche, lorsque le fournisseur d’un AppBuilder propose, au lieu d’un abonnement, un contrat ponctuel spécifiquement adapté à l’utilisateur primaire donné, ceci implique un schéma différent. Il y a, là, une possibilité implicite qu’une fois le logiciel construit, la relation ultérieure entre le fournisseur de l’AppBuilder et l’utilisateur primaire peut cesser. Ceci, à son tour, exige que ledit utilisateur primaire développe une capacité nouvelle d’innovation digitale. Un transfert de technologie de la part du fournisseur est logiquement à espérer. Si, en tant qu’utilisateur primaire d’un AppBuilder, je décide de naviguer, dans l’avenir, les eaux digitales incertaines sans l’assistance de mon fournisseur initial, il me faut le code-source du logiciel. Sinon, je ne pourrais pas modifier mon outil.

Ainsi donc, l’occurrence de ces deux schémas contractuels distincts dans le marché des AppBuilders – le schéma abonnement comme solution majoritaire contre celui basé sur un contrat ponctuel dans une minorité des cas – suggère que le marché d’utilisateurs primaires des AppBuilders est principalement composé d’entités à capacité plus ou moins constante d’innovation digitale, avec une sous-population faite d’organisations capables de développer leur capacité dans ce domaine. De la part du fournisseur de l’utilité type AppBuilder, ceci implique le développement de deux types distincts de compétences en termes de relations-client. D’une part, il faut une compétence d’accompagnement digital d’utilisateur primaire. Il faut rester à jour en ce qui concerne les besoins du client, l’évolution de son organisation ainsi que de son marché, pour préparer des blocs mécano correspondants dans l’AppBuilder. D’autre part, le fournisseur d’un AppBuilder peut ou doit développer la capacité de transférer à son client une partie de la technologie de base, y compris le code-source du logiciel, en cas où le client développe sa propre capacité d’innovation digitale. Ce deuxième cas donne lieu à des solutions intéressantes, par exemple des codes-source multiples (où chaque utilisateur primaire génère, de facto, un code-source individuel pour son logiciel) ou des contrats bien astucieux de transfert de propriété intellectuelle.

L’occurrence apparemment aléatoire des versions gratuites de certains AppBuilders suggère que certains de parmi leurs fournisseurs développent comme un surplus d’innovation digitale : des trucs qui sont toujours utiles pour des applications simples et possibles à utiliser comme appât marketing mais pas suffisamment impressionnants pour qu’un utilisateur primaire sérieux veuille bien payer pour y avoir accès. Ceci, à son tour, implique une course technologique extrêmement rapide dans le secteur, tellement rapide que les créateurs des technologies n’ont même pas de temps suffisant pour exploiter commercialement à fond tout ce qu’ils développent.

Le raisonnement que je viens de présenter débouche sur la question suivante : comment organiser l’étude de marché pour un nouvel AppBuilder de façon à ce que l’AppBuilder en question soit compétitif ? Voilà un carrefour intéressant de la science et du business.

Qu’est-ce que je veux savoir lorsque je lance une nouvelle version du produit qui existe déjà ? C’est une bonne question. Puisque le produit existe déjà, et sa technologie évolue tellement vite que des retombées de ladite évolution sont accessibles gratuitement, il est presque complètement inutile de lancer des sondages, basés sur des questionnaires standardisés du genre « Qu’espérez-vous d’un AppBuilder ? ». Les attentes ainsi formulées sont un pâle reflet de ce qui se passe sur le marché. Comme je viens de le discuter, les proportions entre les compétences digitales d’utilisateurs typiques des AppBuilers, d’une part, et le degré de perfectionnement technologique de ces derniers d’autre part sont ridiculement déséquilibrés. Ces utilisateurs ne sont tout simplement pas capables de dire ce qu’ils veulent puisqu’ils n’ont pas la base se savoir nécessaire pour verbaliser ce qu’ils veulent.

Dans le passé, avant que j’eus choisi la carrière académique, je travaillais précisément dans l’étude de marché comme profession. Par expérience, je sais comme profondément vraie est cette phrase de Bernard Bosanquet : « (…) souvent, lorsque les gens ne savent pas ce qu’ils veulent dire, ils néanmoins veulent dire quelque chose de très grande importance ». En d’autres mots, les questionnaires typiques, faits des questions standardisées, comme dans les sondages s’opinion publique que vous pouvez voir à la télé, sont, parmi tous les outils de recherche, les plus difficiles à utiliser correctement et par ce fait, la plupart de leurs résultats sont tout simplement erronés. L’étude de marché vraiment digne de ce nom exige que l’on se pose des questions fondamentales, tout comme dans une recherche scientifique strictement dite, et que l’on applique toute la rigueur scientifique à trouver des réponses.

Voilà donc que j’ai une occasion toute prête de se tourner vers l’une de mes petites obsessions intellectuelles : la recherche behavioriste. S’il est futile d’étudier ce que les gens disent qu’ils pensent qu’ils veulent, il peut être intéressant ce qu’ils font. Les AppBuilders sont utilisés par les entreprises et les organisations non-commerciales de taille relativement petite et de compétence digitale relativement modeste pour construire rapidement des applications mobiles qui servent à créer, maintenir et développer des relations-clients. C’est le cœur du phénomène étudié de façon scientifique : la façon dont les utilisateurs primaires potentiels d’un AppBuilder gèrent leurs relations-clients.

Une façon de faire quelque chose est une séquence. L’action B se répète, encore et encore, après l’action A et avant l’action C. Si je contacte une agence de voyages, par exemple, ses employés vont se comporter en une séquence d’actions (interview en ce qui concerne mes attentes, un devis personnalisé des voyages, deux appels de relance par téléphone etc.). Point de vue business, l’application mobile qu’une telle agence pourrait offrir à ses clients remplacerait cette séquence d’actions avec quelque chose de plus efficient, au moins en principe. C’est objectivement ce qu’un AppBuilder peut donner, en termes de valeur ajoutée, à cette agence de voyages : une technologie pour cloner – rapidement et facilement – leur séquences typiques d’actions dans les relations-clients en une forme d’application mobile.

J’ai donc pensé à une première phase qualitative de cette étude de marché, basée sur un échantillon d’interviews en profondeur dans les PME et des organisations non-commerciales, précisément en vue d’identifier des schémas comportementaux récurrents. Parmi d’autres détails méthodologiques, une question émerge : la taille de l’échantillon. Dans l’univers du qualitatif, il y a une foule d’opinions à ce propos. En fait, chaque chercheur a sa petite théorie. Ce que je peux définir comme consensus méthodologique assume des échantillons entre 20 et 70 interviews. Je me suis demandé s’il y a une méthode rationnelle de calculer ça.

J’avais commencé par assumer que dans une série d’interviews qualitatifs en profondeur, chaque interview devrait fournir des informations pertinentes pour optimiser les interviews suivantes. C’est une démarche heuristique. J’avais retourné aux notions fondamentales de la méthode de Bayes : chaque expériment consécutif permet de diviser l’univers entiers d’occurrences possibles en deux champs distincts, d’habitude possibles à décrire comme « succès » ou « échec ». Je me suis dit, aussi, que j’ai tout le droit d’attendre à ce que ces interviews marchent, en pratique, suivant la règle de Pareto : 20% d’entre elles vont fournir 80% d’informations utiles. Très intuitivement, j’ai donc calculé, encore une fois en accord avec la logique de Bayes, le coefficient binomial pour une séquence faite de 2 succès sur 10 essais. Ça fait {10!/[(10!*(10-2)!)]} = 45. Le symbole « ! » veut dire, bien sûr, une factorielle. Je sais que c’est vraiment très intuitif, mais une intuition cohérente vaut mieux que rien.

Il y a un second truc, dans cette étude de marché : l’expérimentation avec les prototypes de l’AppBuilder. A ce respect précis, une question méthodologique a surgi : comment savoir quelles caractéristiques de l’AppBuilder sont les plus importantes pour les utilisateurs. La façon la plus simple de se faire une opinion là-dessus est de demander les opinions d’utilisateurs primaires. Encore, pour moi, c’est encore une fois demander ce que les gens disent qu’ils pensent qu’ils attendent de la part de quelque chose qui n’existe pas encore. J’ai donc pensé à une approche behavioriste. Logiquement, si une modification de la caractéristique donnée d’une utilité digitale affecte le comportement d’utilisateurs relativement plus que des modifications d’autres caractéristiques, ce trait précis a la capacité de modifier le comportement, donc il est plus important que les autres. J’ai donc pensé à un expériment où la société d’informatique construit des prototypes dotés des caractéristiques hyperboliques, genre icônes vraiment petites en comparaison avec des icônes très grosses. Chaque hyperbolisation est testée séparément en vue de son impact sur le comportement d’utilisateurs dans l’environnement expérimental.

Voilà un échantillon de la vie d’un scientifique dans le monde réel, lorsqu’il faut utiliser la science pour trouver son chemin dans l’espace social. Je continue à vous fournir de la bonne science, presque neuve, juste un peu cabossée dans le processus de conception. Je vous rappelle que vous pouvez télécharger le business plan du projet BeFund (aussi accessible en version anglaise). Vous pouvez aussi télécharger mon livre intitulé “Capitalism and Political Power”. Je veux utiliser le financement participatif pour me donner une assise financière dans cet effort. Vous pouvez soutenir financièrement ma recherche, selon votre meilleur jugement, à travers mon compte PayPal. Vous pouvez aussi vous enregistrer comme mon patron sur mon compte Patreon . 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 travail ?