I. Une culture de l'innovation en interne

Depuis sa création, Scub a innové avec une approche « Eat your own dog food ». Pour faire simple, cela consistait à créer des solutions qui répondaient aux problèmes que nous rencontrions en interne. Une fois la solution peaufinée, nous la transformions en produit vendable à des clients.

Cette approche avait plusieurs avantages :

  • nous étions sûrs que ce que l'on était en train de créer résolvait des problèmes concrets que d'autres entreprises devaient aussi rencontrer (et ces entreprises pourraient donc éventuellement devenir des clients pour notre solution) ;
  • nous avions un retour sur investissement (ROI) très rapide, car avant même de vendre notre produit, celui-ci améliorait notre productivité et donc nos résultats ;
  • le fait d'être le premier utilisateur de la solution nous permettait de nous assurer de sa qualité et de sa pertinence ;
  • chaque membre de l'équipe connaissait parfaitement le produit et pouvait donc intervenir rapidement chez nos clients.

L'un des exemples les plus concrets est Scub Foundation, notre usine logicielle Java libre, qui permet de produire plus rapidement de meilleurs logiciels et de réduire le « time to market ». Ce produit a été réalisé à partir de nos problématiques en tant que « producteur de logiciels ». Nous avons commencé par identifier les problèmes bloquants que nous rencontrions (industrialisation, bibliothèques, nouvelles technologies, services communs…) puis nous avons développé des solutions qui résolvaient ces problèmes et enfin, nous en avons fait un produit fini qui est aujourd'hui utilisé par plusieurs de nos clients.

II. Un besoin de spécialisation

Le métier de Scub est simple : « Développer des applications sur mesure afin de résoudre les problématiques de nos clients ». Nous pouvons donc répondre à beaucoup de besoins de beaucoup d'entreprises.

Cette particularité rend notre métier intéressant intellectuellement (on passe d'un projet pour un grand groupe pétrolier français à celui d'un des premiers aquariums européen) et nous permet de mieux résister à la crise (tous nos clients ne sont pas touchés au même moment et certains ne la sentent même pas). Le revers de la médaille, c'est qu'il est assez difficile pour nos équipes commerciales de conquérir des nouveaux clients en tapant à toutes les portes et en disant « On ne vous connaît pas mais dites-nous quel est votre problème et nous allons le résoudre ». Bien que Scub Foundation soit un avantage clé, on se retrouvait quand même sur un marché ultra concurrentiel (avec des concurrents allant de l'autoentrepreneur à la grosse SSII indienne de plusieurs milliers de personnes).

Pour l'avenir de Scub, nous souhaitions mettre en œuvre une stratégie basée sur la conquête, l'innovation et l'internationalisation.

Pour réussir ce pari, il nous fallait donc :

  • avoir un produit très ciblé qui nous permette d'attaquer une niche bien précise afin de s'assurer une conquête rapide de nouveaux clients ;
  • avoir un produit avec un positionnement haut de gamme qui nous permette de dégager des marges suffisantes pour alimenter notre innovation sur ce produit ;
  • avoir un produit innovant et éprouvé pour attaquer des marchés à l'étranger et des clients de toutes tailles.

III. La solution : la cocréation

Pour réussir avec un nouveau produit, il nous fallait, au minimum, trois choses : un produit, une niche et une référence client. Sans ces trois éléments réunis, difficile de lancer des équipes commerciales à l'assaut du monde.

Ayant vu trop de SSII/agence web/éditeur (y compris nous) développer des solutions puis essayer de les vendre, j'ai compris que ce n'était pas la bonne façon de faire. En réfléchissant, ce serait quand même mieux qu'un client nous dise d'abord ce qu'il veut, qu'on développe la solution en suivant ses besoins et qu'il achète le produit dès qu'il est fini. Le client aurait ce qu'il veut et nous, nous aurions un produit, une niche et une référence client ?

Nous avons donc opté pour une stratégie de co-création, c'est-à-dire la création d'un produit en faisant travailler, ensemble et dès le début, les équipes développant le logiciel chez nous et les équipes qui allaient utiliser le logiciel chez le client. L'idée derrière cette méthode est que, pour satisfaire un client, il fallait aller plus loin que de simplement lui demander une décision « Oui/Non » sur un produit fini qu'on lui propose. Pour offrir un meilleur produit, ce produit doit être conçu avec le client et pas seulement être conçu par les équipes du fournisseur.

Concrètement, ce processus, basé sur la coopération entre producteurs et utilisateurs, nous permettait de créer un maximum de valeur pour le client final en réduisant fortement les risques de « non-adéquation » du produit et de sa cible.

IV. Lancement du projet

En regardant notre clientèle, il est apparu que nous avions un client avec qui nous travaillions depuis plus de 8 ans, chez qui nous avions développé de nombreuses applications (sites web, tarificateur, SSO, gestion commerciale...), dont nos équipes connaissaient le métier, et surtout, qui avait déjà une démarche d'innovation technologique : il s'agissait de la Smatis, une mutuelle santé.

Après avoir fait un business plan et une étude de marché, nous nous sommes rendu compte que le monde des assurances ne disposait pas de solution de gestion de la relation client adaptée à ce métier. On trouvait, soit des solutions métiers « transformées » en CRM et donc extrêmement chères, soit des CRM classiques (SugarCRM, Salesforce…) « trafiquées » pour prendre en compte les spécificités du secteur.

Nous avions donc trouvé le produit à développer : Une GRC libre adaptée au métier de l'assurance, qui fonctionnerait avec le système d'information existant du client et qui intégrerait tous les modules nécessaires (GED, Téléphonie, E-commerce, comparateur de prix…).

Nous sommes donc allés voir notre client en mettant en avant nos atouts :

  • nos équipes d'ingénieurs ont une réelle connaissance du métier de la mutuelle et de votre fonctionnement ;
  • nous avons développé un nombre important d'applications pour vous, y compris dans des domaines critiques comme la tarification ;
  • ensemble, nous avons industrialisé vos développements et mis en place des méthodologies type Scrum pour réduire votre « time to market ».

Depuis plus de 8 ans, nous assurons la maintenance et l'évolution de tout ce que nous avons développé.

Nous proposions donc un deal gagnant / gagnant : nous développions, pour un prix défiant toute concurrence, une solution répondant parfaitement à tous leurs besoins et, nous, nous disposions d'un produit conçu avec des experts, d'une référence et d'une niche.

V. Réalisation du projet

Le projet s'est déroulé sur un peu plus de neuf mois.

Dès le début, les équipes développant le logiciel chez nous et les équipes pouvant utiliser le logiciel chez le client ont travaillé ensemble à réaliser les maquettes des différents écrans grâce à l'outil Balsamiq et à rédiger un cahier des charges grâce au Wiki (Dokuwiki). En très peu de temps, nous avons pu désigner la plupart des écrans de l'application et les faire valider à un maximum de personnes. Ceux-ci nous apportaient en plus leur expertise du métier et leurs idées.

Cette phase a permis aux utilisateurs de demander tout ce qui leur manquait dans les applications qu'ils utilisaient jusque-là. De notre côté, les trouvailles et idées qui ont émergé pendant ces sessions ont permis d'apporter une vraie valeur ajoutée au logiciel et ceci nous permet aujourd'hui de faire la différence lorsque nous faisons des démonstrations chez des prospects.

Ensuite, nous avons adapté la méthodologie Scrum et nous sommes partis sur des livraisons toutes les trois ou quatre semaines (nous étions partis sur trois semaines mais c'était vraiment trop court). L'ensemble du développement était bien sûr réalisé avec notre usine logicielle Scub Foundation (Eat Your Own Food !).

Au bout d'un an notre solution de CRM pour les mutuelles et assurances est sortie !

VI. L'Open Source

Une dernière chose sur ce logiciel : il est libre, c'est-à-dire que le projet peut être téléchargé, utilisé et modifié par n'importe qui (Il n'y a donc aucune licence à acquérir). Nous considérons ceci comme un des avantages clés de notre solution.

En effet, beaucoup de nos clients hésitent toujours entre « Buy » ou « Build », c'est-à-dire entre « acheter une solution existante et accepter ses contraintes » et « construire une solution sur mesure avec les coûts que cela représente ».

Avec notre expérience, nous sommes persuadés que, lorsque l'outil informatique est une des clés de la réussite pour le métier du client, il faut que celui-ci bâtisse sa propre solution afin qu'elle soit parfaitement adaptée à ses besoins et à ses processus. Avec une solution libre comme SquareCRM, nous permettons à nos clients d'avoir les avantages du « buy » (ils ne partent pas de zéro et réutilisent beaucoup du code existant) et du « build » (ils peuvent adapter la solution à leur système d'information et investir dans les avantages concurrentiels).

Dans les années à venir, de plus en plus d'entreprises vont être séduites par cette approche hybride qui apporte le meilleur des deux mondes. Les logiciels et les technologies vont devenir les principaux outils qui permettront aux entreprises de devenir aussi agiles et réactives que le sont leurs clients. Pour rester compétitifs, nos clients devront parfaitement maîtriser le cycle : « développer, mettre en œuvre, mesurer, évaluer et réagir. »

VII. Remerciements

Merci Stéphane Traumat de nous avoir permis d'héberger son article. Merci aussi à zoom61 pour sa relecture orthographique.