Le logiciel sur mesure devrait s'acheter
Votre équipe a un problème qu'un logiciel pourrait résoudre. Pas un problème célèbre, un problème précis. Les rapports des techniciens prennent des heures au bureau pour être remis en forme et envoyés. Les mêmes chiffres sont ressaisis à la main dans trois systèmes. Le fil d'e-mails est le processus, et il casse dès que quelqu'un part en congé. Vous savez exactement ce qui réglerait ça. Vous ne pouvez l'acheter nulle part.
C'est cette dernière phrase qui nous a poussés à lancer klair. Alors avant le produit, voici le raisonnement qui le porte.
Aujourd'hui, une équipe dans cette situation a trois options, et aucune ne nous plaît vraiment.
Vous pouvez recruter des ingénieurs. Enchaîner quarante entretiens pour en trouver deux qui peuvent commencer dans huit semaines, les engager sur des contrats d'un an, et espérer que ce dont vous aviez besoin est toujours ce dont vous avez besoin le jour de la livraison.
Vous pouvez engager une agence. Payer une phase de cadrage qui se termine par un slide deck, un plan qui gonfle chaque estimation, et un point fixe le jeudi où quelqu'un lit un tableau d'avancement à voix haute.
Vous pouvez le faire vous-même. Bloquer vos mercredis après-midi, brancher un outil d'IA, et regarder le projet caler au quatrième mois quand il propose un changement que personne dans l'équipe ne peut valider en confiance.
Regardez les trois et un motif apparaît. La seule chose que vous ne pouvez pas faire, c'est la plus évidente : l'acheter. Vous pouvez acheter un CRM. Vous pouvez acheter un logiciel de paie, un outil de support, une solution de comptabilité. Chacun a un prix, une inscription, un numéro joignable un dimanche soir. Le logiciel dont votre équipe a vraiment besoin, celui façonné autour de votre façon de travailler, fait exception. Vous pouvez le recruter, le sous-traiter ou le construire vous-même, mais vous ne pouvez pas simplement l'acheter. La version distributeur automatique, où vous décrivez le problème et un logiciel fonctionnel en sort, n'existe pas.
Le logiciel sur mesure est la dernière chose en entreprise qu'on ne peut toujours pas simplement acheter.
C'est ce manque qui justifie tout le reste. Nous trouvions qu'il devait se combler, alors nous nous y sommes attelés. Ce qui suit, c'est ce que cela implique selon nous.
Un atelier qui ne ferme jamais.
La première conviction porte sur le temps, et sur qui doit le dépenser.
Imaginez un atelier qui ne ferme jamais pour la nuit. Vous vous installez un mardi après-midi : café, ordinateur, le problème que vous traînez depuis trois semaines. Vous n'écrivez pas un cahier des charges en partant de zéro. Vous répondez à des questions. À quoi cela doit-il servir ? Qui l'utilisera ? Qu'est-ce qui ne doit jamais déraper ? À quoi ressemble un bon vendredi une fois que ça marche ? Vous répondez, l'atelier rédige le plan à partir de vos réponses, vous le lisez, vous le signez.
Puis vous vous déconnectez.
Pendant la nuit du mardi, le mercredi matin, votre réunion d'équipe, la sortie d'école, l'appel que vous ne pouviez pas déplacer, l'atelier tourne. Il planifie. Il construit. Il vérifie son propre travail et recommence quand quelque chose ne va pas. Chaque étape apparaît en langage clair, qu'une personne non technique peut suivre.
Le mercredi à 09 h 14, il y a un résumé ordonné de tout ce qui a été fait depuis votre dernier passage, et une courte file de travail terminé qui vous attend. Chaque élément est accompagné d'une note sur ce qu'il fait et ce qu'il pourrait affecter.
Vous lisez. Vous signez. Le jalon suivant commence.
Une phrase nous est revenue sans cesse pendant qu'on construisait ça. Ce qui fabrique votre logiciel n'a plus à dormir. La responsabilité, elle, dort toujours, et nous pensons que cela ne devrait jamais changer.
Deux moments humains. Tout le reste, c'est l'atelier.
La deuxième conviction est celle que nous défendrions le plus fort, parce que c'est le choix de structure qui rend la première sûre.
Vous définissez quoi construire. Vous approuvez ce qui est livré. Entre ces deux moments, l'atelier tourne tout seul. Vous n'écrivez pas le logiciel. Vous ne le testez pas. Vous ne le pilotez pas heure par heure. Mais la signature à la fin n'est pas une corvée. C'est une responsabilité, et elle appartient à une personne nommée de votre côté. À chaque fois.
Il n'existe aucun mode « livrer sans moi ». Ni comme réglage, ni comme offre premium, ni comme faveur pour un client de confiance. Nous ne le construirons pas. Nous avons vu trop d'équipes se brûler avec un logiciel livré sans personne pour le réceptionner, et nous préférons perdre la vente que retirer la personne à la frontière. Celle-là n'est pas négociable.
Le moteur qui construit travaille en coulisses. Vous n'avez pas besoin de connaître son nom pour vous en servir. Quand vous nous engagez, nous le faisons tourner pour vous.
À quoi ça ressemble dans la vraie vie.
Si ceci reste un essai et non une théorie, c'est que la version quotidienne n'a rien de spectaculaire, et c'est tout l'intérêt.
Quelque part, il y a une équipe administrative qui passait ses après-midi à transformer des notes de terrain brutes en documents propres et aux normes de la marque, à la main, tous les jours. Un travail minutieux, ingrat, sans fin en vue. Aujourd'hui, le logiciel s'occupe de la mise en forme, et une personne valide le résultat avant l'envoi. Les après-midi sont revenus, et la même petite équipe absorbe bien plus sans se noyer.
Ailleurs, des experts croulent sous des documents à lire, qualifier et structurer avant de pouvoir en faire quoi que ce soit. Une automatisation effectue le premier gros passage et leur remet un brouillon propre. Ils consacrent leurs heures au jugement, la partie qu'eux seuls peuvent faire, plutôt qu'à la mise en forme qui dévorait la journée.
Des équipes différentes, la même forme. Personne n'a recruté d'ingénieur, lancé un projet de six mois, ni changé les outils déjà en place. Elles ont décrit un problème. Elles ont reçu un logiciel fonctionnel. C'est ce résultat que nous cherchons sans relâche, et ce genre de victoire ordinaire que nous préférerons toujours à une démo tape-à-l'œil.
Pourquoi nous avons écrit ceci.
Nous aurions pu commencer par une liste de fonctionnalités. Nous avons écrit ceci à la place, parce que la conviction est venue d'abord et le produit ensuite, pas l'inverse. Le logiciel sur mesure devrait s'acheter. Ce qui le construit peut travailler jour et nuit, et une personne que l'on peut nommer devrait quand même approuver chaque changement livré. Tenez ces deux idées ensemble et vous obtenez la quatrième option, celle qui aurait dû exister depuis le début.
Si votre équipe a un problème qu'un logiciel pourrait résoudre, la porte est ouverte quand vous serez prêt. Les convictions ci-dessus, elles, ne changeront pas.
· · ·
— les fondateurs de klair