remplacer une appli retool que vous avez dépassée. remplacer une appli retool devenue trop grosse arrive quand l'outil interne où vit votre équipe ops arrête de faire gagner du temps et commence à en coûter. le signe n'est pas l'âge de l'appli. c'est la semaine qu'un ingénieur passe à démêler une requête cassée que personne n'a documentée, ou la facture par siège qui grossit plus vite que l'équipe qui l'utilise. la remplacer, c'est posséder le code, l'authentification et la piste d'audit, au lieu de les louer.
l'équipe avait une appli retool. elle faisait tourner ses opérations internes : remboursements, changements de compte, escalades support. elle faisait aussi trois choses qu'elle ne faisait pas au départ. elle se cassait de façons que seul un ingénieur comprenait. elle facturait par siège des personnes qui n'ouvraient qu'un seul écran. et chaque correction impliquait de modifier une config que personne ne voulait posséder. l'appli n'a pas échoué. l'équipe l'a dépassée.
#comment savoir qu'il est temps de quitter retool ?
il n'y a pas de seuil d'utilisateurs qui tranche. on surveille quatre signaux. combien d'heures d'ingénieur par semaine partent à maintenir l'appli en vie. combien de sièges payants appartiennent à des personnes qui ne lisent qu'une seule vue. combien de changements partent en production sans piste d'audit à laquelle personne ne fait confiance. et combien de temps met une nouvelle recrue ops avant d'arrêter de demander à un ingénieur de faire le changement à sa place. quand trois de ces quatre signaux évoluent dans le mauvais sens, c'est l'outil le goulot d'étranglement, pas l'équipe.
quand faut-il remplacer une appli retool par un outil interne que vous possédez ?
remplacez-la quand la maintenir coûte plus de temps d'ingénierie qu'elle n'en fait gagner, quand la tarification par siège dépasse la taille de l'équipe qui l'utilise, ou quand les changements partent en production sans piste d'audit. reconstruisez le ou les deux workflows qui l'ont dépassée en un outil que vous possédez, avec authentification, rôles et journaux. gardez le reste jusqu'à ce que ça fasse mal.
#à quoi a ressemblé le remplacement, concrètement ?
on a fait ça pour une équipe produit saas b2b d'environ 40 personnes. leur appli retool avait grossi jusqu'à des dizaines de requêtes et une gestion des permissions tenue à bout de bras. on n'a pas tout reconstruit d'un coup. on a livré un outil ops interne possédé, avec trois choses intégrées dès le premier jour, pas rajoutées après coup. l'équipe ops est passée entièrement sur le nouvel outil en deux semaines après la bascule.
- une connexion, pour que l'accès soit accordé et révoqué à un seul endroit (authentification)
- un accès basé sur les rôles, pour qu'un chargé de support et un admin voient des écrans différents (rbac)
- un journal d'audit qui enregistre qui a changé quoi, et quand
#pourquoi les ingénieurs ont-ils récupéré une journée par semaine ?
l'appli retool coûtait à l'équipe environ une journée d'ingénieur chaque semaine. ce temps partait dans des requêtes cassées, des demandes d'accès traitées à la main, et des changements qui exigeaient un ingénieur parce que l'équipe ops ne pouvait pas les faire en sécurité. l'outil possédé a transféré ce travail à l'équipe ops. les ingénieurs ont récupéré environ une journée par semaine. on publie ces preuves de construction publique dans le journal.
le sujet et les chiffres présentés ici sont anonymisés conformément à l'accord client. la journée par semaine récupérée et l'adoption en deux semaines sont les chiffres rapportés par le client lui-même, pas des projections.
#n'est-ce pas juste une version plus grosse de la dépendance à un fournisseur ?
we are
on délimite les workflows qui ont dépassé retool et on les reconstruit en un outil interne que vous possédez, avec authentification, rôles et journaux d'audit livrés dans la construction, et on vous remet la base de code dès le premier jour.
we aren't
on n'est pas un abonnement de plus par siège que vous louez indéfiniment, et on n'est pas une reconstruction sur mesure de deux trimestres qui échange une appli qui marche contre une page blanche.
la différence qui comptait le plus pour l'équipe, c'était la propriété. l'abonnement retool qu'ils quittaient facturait par siège et gardait le code sur la plateforme de quelqu'un d'autre. l'outil qu'on a construit est livré comme un dépôt qu'ils possèdent dès le premier jour. pas de tarification par siège. pas de plateforme dont on peut se faire exclure. c'est comme ça que la division platforms construit des outils ops internes.
la semaine où on a arrêté de rafistoler l'ancienne appli, j'ai récupéré mes ingénieurs. c'était tout l'objectif.
si votre équipe n'arrête pas de rafistoler une appli retool que personne ne veut posséder, la réponse n'est pas un rafistolage de plus. c'est de posséder l'outil, l'authentification et la piste d'audit. on délimite, à travers une courte mission de conseil, quels workflows valent la peine d'être déplacés et lesquels laisser tranquilles, puis on construit seulement la partie qui a dépassé l'ancien outil. dites-nous ce que vous construisez.