Si j’étais CEO, je ferais des API
Je n’ai pas fondé de startup mais si je devais en créer une, je m’appuierais sur mon expérience de CTO pour ne pas faire cette erreur trop souvent observée lors de la conception d’un produit et qui conduit inévitablement à ce qu’on appelle communément une “usine à gaz”. Attention, je ne dis pas que je ferais mieux que les autres car je vois bien qu’être CEO n’est pas une tâche facile. Il doit penser à tout, faire les bons choix, donner le cap, régler les soucis du quotidien, subir la pression financière… Sans background technique et avec la tête dans le guidon, certains ont tendance à complexifier les choses, à réinventer la roue et à se perdre dans des détails avec un désir de perfection toujours plus grand. L’autoroute vers le succès peut alors rapidement se transformer en un chemin sinueux. Et pourtant il existe une solution technique qui pourrait résoudre bon nombre de problématiques. Elle doit cependant être prise en compte dès la définition du scope du projet car elle pourrait en changer la nature. Cette solution tient en trois lettres : API.
Startup, ton univers impitoyable
Bienvenue dans le monde magnifique et impitoyable des startup SaaS (software as a service). Oui, vous savez, ce monde où les petits génies du développement sont déifiés, où la croissance est exponentielle, où les dividendes pleuvent et où les utilisateurs se comptent par millions. Des centaines de startups se lancent chaque jour dans la grande épopée de l’appli web avec le secret espoir de siéger un jour aux côtés des plus grands. Allez, avouez, vous aussi pensiez que votre bébé deviendrait une licorne ? Et puis la réalité fait bien vite redescendre sur terre. Et c’est souvent le désenchantement.
Car avoir un outil fonctionnel, c’est bien. En tant que développeur, on a même envie de dire, c’est génial, on en demande pas plus ! Le product owner dira que l’essentiel est d’avoir un outil qui réponde aux besoins. Ce à quoi le business analyst rétorquera qu’il faut déjà comprendre le besoin. Puis viendra le DBA qui dira que la performance est la clé.
L’UX designer clamera haut et fort qu’on ne fera rien sans ergonomie, qu’il faut miser sur l’expérience utilisateur. Le sysadmin s’indignera de ne pas avoir 5 serveurs, du load balancing et de la réplication. Il faut mettre le paquet, nous ne tiendrons pas la charge ! Le QA entrera alors en scène pour vous dire que tout passe par les tests, qu’il faut des process, des test d’intégrations, des reviews…
Mais ne vous inquiétez pas, le scrum master saura rassurer tout le monde : si on suit la méthodologie, tout se passera bien. Après tout, des milliers d’entreprises utilisent SCRUM, non ?
Les pieds sur terre
Puis viendra le moment fatidique, la confrontation avec le réel, la remise en question : c’est l’entrée en jeu du commercial. C’est le moment où tout s’effondre, où l’on comprend que ça sera dur et surtout, que tous nos efforts pour construire le meilleur outil que l’Homme ait jamais connu sont réduits à néant par le simple fait que personne ne le connaît. On vous expliquera qu’il faut investir autant sinon plus dans le marketing et le commerce que dans la technique. Or, vous avez déjà tout dépensé ! C’est le moment où vous voudrez revenir en arrière. Vendre un outil imparfait, c’est certainement mieux que de ne rien vendre.
Ce sera la fin de l’histoire pour beaucoup de startups. Les autres connaîtront les joyeusetés du support, de la maintenance, des crashs, des bugs, des problèmes serveurs, etc.
Pour les besoins de l’histoire, admettons quand même que vous avez passé ce cap difficile, en partie grâce à votre bonne étoile. Vous rencontrez enfin votre marché, vous réussissez à convertir quelques utilisateurs et à générer du revenu. Certes, vous n’êtes pas rentable mais vous en prenez la voie. Champagne ?
Malheureusement, ce n’est toujours pas suffisant. Il vous faudra grossir davantage pour survivre. Vous opterez probablement pour des techniques de growth hacking pour booster votre base d’utilisateurs. Enfin, toujours suivi de près par votre bonne étoile, vous trouverez peut être le graal : la rentabilité.
Il ne manquerait pas quelque chose ?
Ai-je oublié quelque chose ? Avez-vous le sentiment qu’une brique manque ?
Si ce n’est pas le cas, lisez la suite avec attention. En effet, une étape essentielle a été omise dans ce récit. Une étape qui devient incontournable dans le monde d’aujourd’hui : je veux bien évidement parler des API.
Une API (Applications Programming Interface) est un point d’entrée dans votre application. C’est une interface entre votre application et le monde extérieur qui permet à d’autres systèmes de se connecter à votre outil. Grâce aux API, deux applications peuvent communiquer entre elles de manière automatisée pour échanger des informations, se synchroniser, intégrer une fonctionnalité et bien d’autres choses encore. Elle permettent avant tout de ne pas réinventer la roue : si une autre application fait de la facturation et que ce n’est pas votre coeur de métier, pourquoi refaire ça en interne ? Vous ferez probablement moins bien qu’un spécialiste et perdrez votre temps/argent/énergie à développer des fonctionnalités qui n’ont rien à voir avec votre métier.
Dans le monde d’aujourd’hui, tout est connecté : votre frigo communique avec votre téléphone ; et votre app, avec quoi communique-t-elle ?
Indispensables API
Ne pas construire d’API, c’est vivre en autarcie, coupé du monde. C’est penser son outil en dehors de son environnement. C’est aussi penser que rien ne peut l’améliorer, qu’il est parfait et autonome ainsi.
Le monde évolue aux antipodes de cette conception. Les apps sont de plus en plus spécifiques : elles font peu mais elle le font bien. Elle se connectent entre elles pour offrir le meilleur aux utilisateurs. Si les géants du web n’avaient pas conçu d’API, ils ne seraient pas devenus ce qu’il sont aujourd’hui.
De plus, en vous connectant avec d’autres systèmes, vous vous faites connaître, vous gagnez en visibilité, vous touchez plus de monde, vous profitez du succès des autres.
Créer une API, c’est aussi repenser votre outil. Vous pouvez ainsi vous concentrer sur l’essentiel, sur votre métier, sur ce que vous savez faire et déléguer le reste à meilleur que vous.
Dans un monde meilleur
Voyons ce que la mise en place d’une API aurait changé dans le récit ébauché ci-dessus.
Imaginons un instant que vous ayez mis vos API au coeur de votre système. Vous auriez recentré votre coeur de métier, vous auriez diminué le scope de votre MVP. Vous auriez donc produit un outil beaucoup plus petit et vous l’auriez intégré avec d’autres pour fournir autant sinon plus de fonctionnalités à vos utilisateurs (sans parler du gain de qualité). Vous auriez donc passé moins de temps sur le développement, ce qui veut dire moins de maintenance, moins de problèmes techniques (serveur, UX, DB, etc.). Cela vous aurait incontestablement laissé plus de ressources pour passer le cap de la commercialisation. Et même si l’échec était inévitable, vous auriez échoué plus vite et les raisons de votre échec auraient été plus claires.
Les API vous auraient également aidé dans les étapes ultérieures. Vous auriez pu profiter d’une partie des clients de vos partenaires ainsi que de leur notoriété lorsque vous cherchiez à accroître votre base d’utilisateurs. C’est gagnant-gagnant.
Alors convaincus ? :)
De mon côté, je suis persuadé qu’une API REST claire et robuste est un atout majeur pour une startup SAS. Elle s’inscrit dans une vision moderne, collaborative et modulaire de l’informatique dans laquelle les différents systèmes sont vus à l’échelle globale et non individuelle.
Ce n’est bien sûr pas au CEO de concevoir cette API mais c’est à lui d’en tenir compte lors de la définition du scope du projet car celui-ci ne sera pas le même avec une API. Certes, concevoir des API ne sera pas l’essence même de votre métier mais cela vous permet de vous connecter au monde extérieur, ce qui n’est plus une option au 21ème siècle.
