La plupart des logiciels dont une entreprise a besoin ne sont jamais construits. Non parce que c'est difficile, mais parce qu'il n'y a personne pour les construire avec le métier qu'il faut.
Le nom
Dans le kabuki, le théâtre classique japonais, il y a sur scène des personnes que le public accepte de ne pas voir : les kuroko. Vêtus de noir de la tête aux pieds, ils déplacent les décors, tendent l’éventail à l’acteur au bon moment et changent un costume en quelques secondes, sous les yeux de tous.
Kuro vient de kuroko. Tomo (友) signifie ami. Kurotomo, c’est l’ami derrière le rideau : nous faisons le travail pour que vous soyez le protagoniste.
Le noir (dans ce contexte) signifie invisible. L’acteur brille ; le kuroko le rend possible.
01
Écrire du code est aujourd'hui plus rapide que jamais. L'autocomplétion et le chat ont réglé cette partie, et pourtant les listes de tâches continuent de grandir.
Parce qu'écrire n'a jamais été le goulot d'étranglement. Le coûteux, c'est tout le reste : comprendre ce qu'il faut vraiment, l'intégrer, le tester, le relire, le déployer et ne rien casser en chemin. C'est là que part le temps des gens, et c'est là que presque personne n'a rien automatisé.
02
Ce que nous automatisons n'est pas l'écriture du code. C'est la façon de travailler de professionnels qui livrent des logiciels depuis plus de 30 ans : les méthodes qui ont tenu, les décisions qui ont évité des désastres, les leçons qui ont coûté cher. Ce processus a été affiné et poli pendant des années.
C'est exactement là qu'est la différence avec un modèle laissé seul. Le modèle écrit ; le processus décide quand comprendre, quand demander, quand tester et quand s'arrêter pour attendre une personne. C'est cela que tout le monde peut désormais utiliser, et plus seulement ceux qui ont une équipe chevronnée en interne.
03
Kurotomo n'est pas un assistant de plus qui suggère des lignes pendant que quelqu'un code. C'est tout le processus : il prend le ticket, l'affine s'il est ambigu, l'implémente, le teste, ouvre la demande de fusion et déploie.
Le résultat n'est pas du code suggéré dans un éditeur. C'est un changement qui fonctionne, avec son historique et sa traçabilité, prêt à être approuvé.
04
Un système qui tourne sans supervision n'est pas une promesse, c'est un risque. C'est pourquoi le flux comporte des portes : contrôle qualité et approbation humaine avant que quoi que ce soit n'atteigne la production.
Vous décidez où va chaque porte. La différence, c'est que vous cessez d'accompagner chaque ticket du début à la fin et n'intervenez que là où votre jugement change le résultat.
05
Cela ne remplace pas les développeurs. Cela leur enlève la part du métier que personne ne regrette : la répétition, la colle entre les systèmes, le même déploiement que d'habitude, le ticket qui attend depuis deux semaines.
Ce que cela rend, c'est du temps. Du temps pour le jugement, l'architecture et les problèmes qui méritent vraiment une tête humaine. Et du temps pour ne pas être scotché à une liste de tickets à onze heures du soir.
06
On paie par projet actif, pas par ticket. Facturer le travail livré punit exactement ce que nous voulons voir arriver : que vous demandiez davantage.
Un projet éteint ne coûte rien, les tickets sont illimités et chaque projet supplémentaire coûte moins cher. Tous les chiffres que nous publions viennent du même endroit que votre facture.
07
Votre code reste dans vos dépôts, votre outil de tickets reste le vôtre et vos déploiements gardent leur calendrier. Il n'y a aucune plateforme vers laquelle migrer.
Chaque client tourne sur sa propre instance, avec ses identifiants chiffrés. Et vos données ne servent à entraîner aucun modèle : c'est écrit dans notre politique de confidentialité, pas seulement ici.
La meilleure façon de savoir si cela vous convient est de lui donner quelque chose à construire.
