Pourquoi nous avons créé nos propres outils plutôt que d'utiliser l'existant
Comment la création de k-notes, k-tasks et k-cv a transformé notre façon de penser le logiciel — et pourquoi "utilisez simplement un outil existant" n'est pas toujours le bon conseil.
Nous conseillons nos clients sur le moment opportun pour développer un logiciel sur mesure et celui de s'appuyer sur des solutions existantes. Il serait incohérent de ne pas appliquer ce même raisonnement à nous-mêmes.
Alors quand nous avons décidé de créer k-notes, k-tasks et k-cv, la question qui revenait naturellement était : pourquoi ? Notion existe. Trello existe. Il existe des dizaines de créateurs de CV. Qu'est-ce qui vous a convaincus de développer les vôtres ?
Voici la réponse honnête.
Nous voulions des outils qui fonctionnent comme nous pensons
La plupart des logiciels de productivité sont conçus pour l'utilisateur moyen, dans tous les cas d'usage possibles. C'est une stratégie produit raisonnable. Cela signifie aussi une grande complexité que la plupart des gens n'utilisent jamais.
Nous prenons des notes en permanence — pendant des appels, en lisant, quand une idée surgit à 23h. Nous voulions un éditeur qui s'ouvre instantanément, qui sauvegarde automatiquement, et qui ne se mette pas en travers de notre chemin. Notion est un excellent logiciel, mais ce n'est pas ça. Chaque document vit au sein d'un système de workspace qu'il faut naviguer. Nous cherchions sans cesse une application de notes qui s'ouvre comme une page blanche.
Alors nous en avons construit une.
La même chose s'est produite avec la gestion de tâches. Nous avons utilisé Trello pendant des années. Puis Asana. Puis Linear. Chacun résolvait certains problèmes et en créait d'autres. Nous voulions un outil kanban où créer une tâche se faisait en un clic, où l'interface ne nécessitait pas de formation pour être comprise, et où la version gratuite ne ressemblait pas à un essai déguisé. Nous avons préféré le construire.
Nous attachons de l'importance à la maîtrise des données
Nous sommes une entreprise européenne, et des pratiques qui sont banales en Silicon Valley ne sont pas toujours acceptables ici — ni légalement, ni éthiquement. Lorsque vous utilisez un outil SaaS américain gratuit, le modèle économique repose généralement sur la publicité ou la cession de données. Vos notes, vos tâches, vos documents de carrière : vous êtes le produit.
Nos produits fonctionnent sur une infrastructure européenne (Neon Postgres avec résidence des données en UE) et notre relation avec les utilisateurs est simple : vous payez un abonnement, nous stockons vos données, nous ne les vendons pas et nous ne les exploitons pas. La conformité RGPD n'est pas une case à cocher légale pour nous — c'est une exigence de conception.
Construire des logiciels fait de vous un meilleur partenaire de développement
Chaque fois que nous avons livré une fonctionnalité produit, nous avons rencontré les mêmes problèmes que ceux de nos clients : des exigences floues, un périmètre qui dérive, la tension entre vitesse et qualité, des décisions qui semblaient anodines et se sont révélées fondamentales.
Gérer nos propres produits nous a rendus de meilleurs conseils. Quand un client dit "on veut juste ajouter un truc de plus", nous savons exactement ce que cela implique généralement pour un calendrier. Quand quelqu'un pose des questions sur les choix de schéma de base de données, nous avons vécu ces conversations à 2h du matin en essayant de résoudre un problème en production.
Avoir quelque chose à perdre change votre façon de penser le logiciel.
Ce que nous avons appris (et ce qui nous a surpris)
La partie la plus difficile n'était pas l'ingénierie. C'était de décider ce qu'il ne fallait pas construire.
Chaque produit que nous livrons comporte une liste de fonctionnalités que nous avons délibérément laissées de côté. k-notes n'a pas de mode wiki. k-tasks n'a pas de diagramme de Gantt. k-cv n'a pas d'IA pour rédiger votre section expérience à votre place. Les utilisateurs nous les demandent. Nous refusons.
C'est plus difficile qu'il n'y paraît. Le réflexe naturel face à une demande de fonctionnalité est de dire oui. Dire non exige une idée claire de ce à quoi le produit est destiné — et la volonté de décevoir certains utilisateurs potentiels pour mieux servir les utilisateurs principaux.
Les applications fonctionnent grâce à ce que nous avons supprimé, pas à ce que nous avons ajouté.
Pourquoi nous vous en parlons
Nous ne vous racontons pas cette histoire pour suggérer que construire ses propres outils est toujours le bon choix. Ce n'est pas le cas. Il existe d'excellents produits existants pour la plupart des besoins courants, et les utiliser est généralement la décision raisonnable.
Mais pour nous, construire nos propres outils n'était pas une question de prestige. C'était le seul moyen d'avoir exactement ce dont nous avions besoin, en accord avec nos valeurs, et que nous pouvions maintenir et faire évoluer nous-mêmes. Ces produits existent parce que nous les utilisons — pas comme exercice de portfolio.
Si vous construisez quelque chose et souhaitez réfléchir à la question de construire ou acheter, nous avons un point de vue tranché et nous ne vous dirons pas simplement ce que vous voulez entendre.