L’une des grandes questions qui se pose pour toute société technologique, et en particulier pour une startup, c’est comment créer une barrière à l’entrée qui soit efficace ? En particulier lorsque la société introduit une nouvelle technologie. Quid des brevets? Comment assurer une pérennité de la croissance et assurer une bonne compétitivité dans le temps?
Les brevets sont souvent un moyen de se rassurer et aussi de valoriser économiquement son savoir faire, en particulier à l’occasion d’une levée de fond, ou pour impressionner ses clients. Mais à moins de disposer de moyens importants et d’avoir des brevets “en béton”, il s’agit de tigres de papier malheureusement contournables par les concurrents. Et ils ne procurent pas d’effet de levier suffisant pour accélérer le développement de l’entreprise. Sauf à entrer dans un modèle de concession de licences (royalties) sur de très gros volumes, ce qui est plutôt rare. Et puis l’aspect “arme de dissuasion” des brevets est assez opérant aux USA mais plus modéré en Europe.
Le point clé consiste à générer une inertie de marché favorable à son offre. Cela passe nécessairement par la création d’un écosystème de produits et de compétences complémentaires à son offre. Plus les compétences et produits complémentaires seront nombreux, plus la société sera difficile à déloger par un concurrent. Plus les “coûts de migration” (switching costs) de l’écosystème seront élevés, meilleure sera la protection. De nombreux succès de la high-tech et même au delà s’expliquent en grande partie par cet effet écosystème. C’est le genre d’approche qui a permis aux “first movers” sur le marché de survivre. Les “first movers” qui n’avaient pas un écosystème suffisamment dense se sont souvent fait remplacer par d’autres.
Il faut bien entendu s’attacher à respecter la loi, surtout si l’on est en situation de domination d’un marché. Mais les startups ne sont à priori pas dans ce cas là.
Encore faut-il penser la conception de ses produits et services, ainsi que dans sa stratégie vente et marketing, pour créer un vaste écosystème.
L’une des approches à considérer consiste à investir une part non négligeable de sa R&D dans la partie du produit qui permettra l’éclosion d’un écosystème de produits complémentaires. Il faut donc conçevoir idéalement une architecture du produit qui le rendra extensible. Pour un logiciel ou un site Web, il faudra que le code soit très modulaire. Il faudra que l’interface entre les modules soit clairement documentée. On pourra utiliser XML et Services Web pour se relier à d’autres systèmes. On pourra aussi créer une architecture du plug-ins, un kit de développement. On passera du temps à bien documenter l’ensemble et fournir des exemples de code facile à imiter et modifier. Bref, une approche qui devra être pensée en amont. Et qui se heurte parfois à la nécessité de coder rapidement la première mouture de son logiciel.
Ceci a certainement un coût non négligeable mais c’est surtout le résultat d’une approche et d’une discipline. Il peut-être difficile d’accepter de se poser et de ralentir le rythme d’ajout de fonctionnalités pour permettre plutôt à d’autres de le faire. Il est aussi critique de délimiter ce que l’on peut faire soi-même et ce que l’on fera faire par d’autres. Le produit de la société pourra par exemple être “horizontal” et les outils additionnels “verticaux” (selon l’industrie des clients). Mais cette discipline aura une vertu interne: elle permettra aussi une croissance saine et maitrisée de l’équipe de R&D de la société et favorisera le travail d’équipe et la répartition des tâches en son sein. La modularité d’un logiciel a autant d’avantages en interne qu’en externe!
L’aspect délicat est que le démarrage de l’activité d’une startup passe souvent plus par l’acquisition de nouveaux clients que de nouveaux partenaires. Les tiers ne s’investissent généralement qu’une fois le produit éprouvé avec des clients de renom. Il est donc utile de prévoir cela en amont dans la conception de l’offre plutôt que de devoir investir dans des modifications alors que l’entreprise est en pleine explosion. Histoire justement d’éviter d’exploser en vol.
Au bout du compte, il vaut toujours mieux vaut être une “platform company” qu’une “product company” ou une “feature company”.
Une “feature company” propose un produit qui est en fait un add-on d’un produit établi sur le marché. Elle fait donc partie de son écosystème. Si elle n’est pas elle-même accrochée à plusieurs écosystèmes concurrents, elle sera très dépendante et facilement commoditisable. Exemples? Le marché des add-ons et utilitaires autour des systèmes d’exploitation, de Photoshop ou d’Office. Il est très large mais peu d’acteurs y ont une taille critique. Et la concurrence y est rude entre freeware, shareware, opensourceware et logiciels commerciaux classiques.
Une “product company” propose un produit qui se suffit à lui-même. Elle est moins dépendante de la plate-forme sous-jacente, et est éventuellement portable sur plusieurs de ces plates-formes. Le mieux dans un tel cas est de prévoir un développement par extension de gamme et par “cross selling”.
Une “platform company” propose des solutions extensibles par d’autres. C’est le nirvana de la high-tech et le modèle de succès ultime. Les exemples de produits de type “plate-forme” abondent. Le meilleur est Windows. Une nouvelle version de Windows (qui certes n’émane pas d’une startup…) met bien en oeuvre ce principe. Il y a la partie visible pour les utilisateurs. Et la partie visible pour les développeurs de logiciels et de matériels. Pour Windows Vista, cette partie cachée aux utilisateurs est aussi importante que les évolutions de l’interface utilisateur du système d’exploitation. Des technologies comme Windows Presentation Foundation faisant partie du “.NET Framework 3.0” permettront aux développeurs de créer des “killer applications” avec une ergonomie sans commune mesure avec ce que l’on fait aujourd’hui sous Windows XP.
C’est aussi une différence clé entre la XBOX et la PlayStation qui à la longue pourrait aider Microsoft sans que les utilisateurs n’y voient que du feu. En effet, il est beaucoup plus facile de développer un jeu pour la XBOX que pour la Playstation du fait d’outils de développement plus puissants et apportant un meilleur niveau d’abstration. D’autres exemples au delà du cas de Microsoft? Adobe Premiere (montage vidéo), CATIA de Dassault Systèmes (CAO 3D), Firefox, MySQL et de nombreux autres logiciels libres, l’architecture Intel, la base de donnée Oracle, etc. Ils sont évidemment plus faciles à trouver avec des produits leaders sur leur marché qu’avec des startups encore en devenir.
Il y a des cas à éviter comme créer une plate-forme largement répandue avec un vaste écosystème mais qui ne rapporte pas beaucoup à son créateur. C’est la situation de Java, créé par Sun Microsystèmes. On ne peut pas dire que Sun ai pu en tirer beaucoup de revenus (la part du logiciel dans leur chiffre d’affaire est très faible). Même s’il est possible que sans Java ils seraient peut-être déjà morts alors qu’ils survivent encore. Et depuis quelques années, les évolutions de Java ont échappé à Sun, du fait du “Java Community Process” mis en place et aussi du rôle croissant d’IBM, notamment sur J2EE (pour faire simple, la version de Java pour les serveurs).
L’autre cas extrème de la plate-forme, c’est le standard ou la norme. Pour consolider sa position sur le marché, une société peut décider de soumettre les interfaces avec son produit sous forme de norme ou de standard à des organismes internationaux idoines (ISO, ECMA, etc). Ce jeu mérite un post à part entière et il est rarement du ressort d’une startup.
En conclusion, il est critique de bien aligner sa R&D avec la stratégie marketing de création d’un canal de partenaires à valeur ajoutée. Et d’équilibrer les investissements technologiques comme marketing entre clients et écosystème. On préparera en tâche de fond l’écosystème dans la conception du produit pour déployer à fond l’approche marketing écosystème une fois son offre démontrée auprès d’une masse critique de clients.
Une partie de tout ceci a été bien décrite dans “Inside the tornado” de Geoffrey Moore, l’une des référence dans l’analyse de la percée d’innovations dans la high-tech. Le bouquin commence à dater (1995) mais reste tout à fait valable!
Nous verrons dans un prochain post le lien qui peut exister entre écosystème et intégration de marché horizontale ou verticale en prenant l’exemple d’Apple avec le Macintosh et l’iPod.
Reçevez par email les alertes de parution de nouveaux articles :