VENËEN

Retour d'expérience · Technique

Un logiciel métier en seize jours, et les garde-fous qui le rendent défendable.

par José Vazquez

7 août 2026 · Voir HORALIO en production →

Un cabinet d'audit et d'expertise comptable s'est doté d'un logiciel de suivi du temps, sur mesure, testé, documenté, en production, en seize jours. L'application est en service et lui appartient. Elle tourne à l'adresse horalio.net. Ce qui a été rare dans ce projet n'est pas la génération de code. C'est la discipline qui a permis d'oser le mettre en production.

Voici le retour d'expérience technique, en deux parties : comment on construit, puis ce que cela change. Ce qui est rare n'est pas la vitesse, c'est le jugement qui la dirige.

1. Ce que la vitesse déplace

Quand une machine produit du code plus vite qu'un humain ne le relit, le risque change de nature. Il n'est plus dans la difficulté d'écrire, il est dans la dérive silencieuse : une convention qui s'effrite d'une session à l'autre, une décision d'architecture oubliée puis contredite trois jours plus tard, une règle métier posée à l'écran mais pas au bon endroit, un test rouge contourné parce qu'on est pressé.

Rien de tout cela n'est spectaculaire. C'est exactement pour cette raison que c'est dangereux. Un projet assisté qui échoue n'explose pas, il pourrit.

Tout ce qui suit n'a qu'un objet : rendre la dérive impossible sans qu'on s'en aperçoive. C'est cela, et non la génération, qui constitue le savoir-faire.

2. L'origine et le périmètre réel

Un cabinet d'audit et d'expertise comptable veut agiliser ses processus internes et se doter d'un logiciel de suivi du temps « ultra simplifié ». Toute la conception s'est appuyée sur ce mot, et il vaut la peine de s'y arrêter, parce qu'il est trompeur. L'ultra simple est multidimensionnel et coûteux à produire. C'est un résultat, pas une caractéristique : ce qui reste une fois tous les arbitrages tranchés. Un logiciel riche est un logiciel qui n'a tranché sur rien et qui a reporté chaque décision sur l'utilisateur, en la déguisant en liberté de configuration. C'est très largement plus facile à construire.

Cinq dimensions distinctes, qui ne se réduisent pas les unes aux autres : simple à saisir (nombre de gestes, valeurs par défaut justes, absence de navigation), simple à apprendre (promesse falsifiable : ou bien un nouveau collaborateur y arrive seul, ou bien elle est fausse), simple à adopter (l'outil parle le vocabulaire de la maison, il n'y a rien à traduire), simple à lire (le responsable qui consulte n'a pas les besoins du collaborateur qui saisit, et la simplicité de la lecture ne se déduit pas de celle de la saisie), simple à maintenir (moins d'options, moins d'états, moins de combinaisons à tester).

Deux conséquences d'ingénierie commandent tout le reste. D'abord, la simplicité remonte jusqu'au modèle de données. Elle ne se joue pas dans l'interface. Si la structure conçoit mal le monde du client, aucun écran ne pourra être simple : il faudra demander à l'utilisateur de compenser à la main ce que le modèle ne sait pas représenter. Une interface compliquée est presque toujours le symptôme d'un modèle qui pense de travers. Ensuite, la génération assistée rend la simplicité plus difficile à tenir, pas plus facile. Tant qu'ajouter une fonction coûtait cher, le budget arbitrait à notre place. Quand l'ajout devient presque gratuit, ce garde-fou disparaît : la machine ajoutera tout ce qu'on lui demande, immédiatement, proprement, sans jamais objecter. La simplicité cesse d'être une contrainte budgétaire pour devenir une pure affaire de jugement.

Deux autres exigences complètent la commande : de très fortes capacités de personnalisation (types de missions, libellés, règles, dossiers), et la constitution d'un actif pour l'entreprise. Ce qui est personnalisé n'est pas un jeu d'options offert à l'utilisateur, c'est la structure elle-même, arbitrée avant la première ligne de code. Et le vrai gisement n'est pas la saisie, c'est la donnée qu'elle produit : traçabilité interne pour le pilotage des missions, transparence vis à vis du client sans exposer coûts ni marges, et fiabilisation des remontées réglementaires auprès de la supervision de la profession, où la qualité des déclarations dépend directement de la fiabilité des temps déclarés.

Les chiffres, pour situer :

Lignes versionnées : environ 39 100.
Commits en seize jours : 269 (premier le 7 juillet, mise en production le 21).
Composants d'interface : 122.
Tests automatisés : 163 au moment de la mise en production.
Rôles d'assistance orchestrés : 8.
Côté serveur : 14 modules d'actions serveur, 10 routes applicatives, 25 modules de logique métier pure, sur une base relationnelle de 805 lignes de schéma et 23 migrations.

Le périmètre, et ce qu'on sous-estime toujours. L'interface (environ 23 400 lignes, 122 composants) couvre la saisie, les tableaux de bord, les rapports, le paramétrage, un parcours d'accueil en six étapes et une version mobile unifiée. C'est la partie que l'assistance génère le plus vite, et celle où « ça a l'air fini » trompe le plus. Le serveur porte l'essentiel : isolation entre cabinets, contrôle des accès, calculs de budget. Invisible, mais c'est le vrai produit. La recette est la part la plus sous-estimée, et elle a coûté autant que le développement : 163 tests automatisés, des passes manuelles allant jusqu'à cinquante-cinq points de contrôle en une fois, quatre jeux de données reflétant les vrais dossiers, et une recette navigateur systématique avant chaque livraison.

Le développement au fil de l'eau, sans recette, n'est pas du développement rapide. C'est du développement amputé.

3. Cadrage : l'assistance accélère, elle ne décide pas

L'assistance excelle à produire un cahier des charges, des scénarios d'usage et un modèle de données en quelques heures. La limite arrive vite, et elle arrive toujours au même endroit : au premier changement qui touche la structure.

Le cabinet demande que plusieurs collaborateurs puissent intervenir sur un même dossier. En base, l'affectation reposait sur une relation simple, un collaborateur pour un dossier. Le faire proprement supposait une table de liaison et, dans la foulée, une refonte du contrôle d'accès. Un développement au fil de l'eau aurait bricolé un contournement dans la nuit. La bonne décision a été de suspendre, d'arbitrer avec le client, et de traiter la demande comme un chantier.

L'expérience, c'est savoir ce qu'on ne code pas tout de suite.

4. Le modèle du monde du client

Cette décision mérite qu'on s'y arrête, parce qu'elle touche au véritable objet de ce projet et au seul actif difficilement reproductible. Le terme consacré est l'ontologie. Je l'emploierai peu, parce qu'il fait fuir et qu'il fait croire à de la théorie. Il s'agit d'une chose très concrète : les objets dont une organisation parle, les règles qui les gouvernent, et l'ordre dans lequel ces règles s'appliquent. Ses noms, ses verbes, sa grammaire.

Ce n'est pas le schéma de base de données. Le schéma en est une implémentation, à un instant donné, dans une technologie donnée. On peut implémenter parfaitement un modèle faux, et c'est même le cas le plus fréquent : normalisé, indexé, contraint, et décrivant un monde qui n'est pas celui du client.

Un exemple tiré de ce projet. La cascade de taux appliquée aux temps saisis suit un ordre de spécificité strict, du plus particulier au plus général : un taux fixé pour un collaborateur sur un projet donné l'emporte sur un taux de projet, qui l'emporte sur un taux de client, qui l'emporte sur le taux du cabinet. Techniquement, c'est une fonction de résolution de quelques lignes. Conceptuellement, c'est une affirmation sur le monde : ce cabinet tient que le particulier prime toujours sur le général en matière de valorisation. Un autre cabinet pourrait décider l'inverse. Aucun logiciel générique ne pose jamais cette question, et c'est pour cela que tant d'utilisateurs corrigent leurs états à la main après extraction. Cette règle est extraite en fonction pure et testée, précisément parce qu'elle n'est pas technique. Le code peut changer, la règle non.

Le premier geste de cadrage : demander les fichiers parallèles. La façon la plus rapide de détecter un désaccord entre le modèle installé et le métier réel est de regarder ce qui gravite autour du logiciel officiel. Des tableurs tenus à la main que personne n'a commandés, des champs libres remplis de codes transmis oralement, des conventions de nommage qui portent une information structurée que l'outil ne sait pas stocker, une double saisie que plus personne ne conteste parce qu'elle date d'avant tout le monde.

Ces artefacts ne sont pas de l'indiscipline. Ce sont les fragments du métier réel, expulsés du système parce qu'il ne savait pas les accueillir, et réinjectés à la main par des gens qui savent de quoi ils parlent. Chacun est une spécification gratuite, déjà rédigée, qui attend d'être lue. C'est la première chose que je demande en arrivant, avant toute discussion de besoin : montrez-moi vos fichiers parallèles. Une heure passée dessus vaut une journée d'atelier.

Pourquoi cela ne se recueille pas par écrit. L'essentiel est tacite. Demandez à un associé ce qu'est une mission : vous obtiendrez une définition claire, en une phrase, immédiatement. Observez ensuite le cabinet travailler, et vous trouverez plusieurs catégories de missions au comportement distinct, dont certaines qu'il n'aurait jamais pensé à mentionner parce qu'elles vont de soi. Ce n'est ni de l'imprécision ni de la rétention. C'est la nature du savoir professionnel : ce qu'on maîtrise le mieux est ce qu'on explicite le moins. La technique qui fonctionne est contre-intuitive : proposer une formulation délibérément approximative et attendre la correction. Un modèle affiché et légèrement faux déclenche en trente secondes un « non, pas tout à fait, en réalité c'est plutôt... » que trois réunions de recueil n'auraient pas produit. C'est la justification technique, et non commerciale, du travail sur place.

Un critère opérationnel, transposable dès demain. Une demande arrive. Avant de l'estimer, posez une seule question : jusqu'où se propage-t-elle ? Si elle reste sur un écran, c'est une fonctionnalité. On l'estime, on la planifie, on la livre. Si elle touche en même temps le contrôle d'accès, les rapports et l'historique, ce n'est pas une fonctionnalité. C'est le modèle qui était faux, et cela devient un chantier. L'épisode des dossiers partagés en est l'illustration exacte : « plusieurs collaborateurs sur un dossier » se présentait comme un champ à dupliquer, deux heures de travail. En réalité le système tenait pour acquis qu'un dossier appartient à un collaborateur, et les règles de confidentialité dérivaient de cette appartenance.

La propagation est la signature. Et c'est précisément là qu'un développement assisté non dirigé produit son pire résultat. La machine sait parfaitement créer une table de liaison, migrer les données et adapter les écrans. Elle ne sait pas qu'en faisant cela elle vient d'invalider silencieusement un modèle de sécurité. Le code compilera, les tests existants passeront, et la faille attendra la recette. Ou pire, la production.

Ce qui est réellement possédé. Nous disons que le cabinet possède son logiciel. C'est exact du code et des données. Mais la valeur durable n'est pas là. Le code a une espérance de vie de quelques années, et la génération assistée rendra son remplacement presque indolore. En revanche, la manière dont un cabinet d'audit conçoit une mission, un temps déclarable, une règle de confidentialité vis à vis d'un confrère, évolue à l'échelle d'une décennie. Ce que le cabinet possède réellement, c'est le modèle explicite et formalisé de son propre travail. Le code qui l'exprime aujourd'hui pourrait être régénéré en quelques jours à partir de ce modèle. L'inverse n'est pas vrai. La pile technique de ce projet se copie en une après-midi. La compréhension de la façon dont un commissaire aux comptes justifie son temps devant sa supervision ne se copie pas, parce qu'elle ne se trouve écrite nulle part.

5. Architecture et règles métier, là où la génération devient dangereuse

Le cœur du produit, ce sont des règles de confidentialité : qui voit quoi, et surtout qui ne voit pas quoi. Le piège du code généré vite est toujours le même : la règle est posée là où elle se voit, c'est à dire dans l'interface, et nulle part ailleurs. Un contrôle constaté en recette l'illustrait parfaitement : une interdiction de saisie correctement affichée à l'écran, mais absente côté serveur, donc contournable par un appel direct.

Une règle métier non gardée côté serveur n'existe pas.

Le principe paraît élémentaire, et il n'est pourtant pas toujours respecté par des logiciels du marché installés de longue date, où un contrôle affiché à l'écran se contourne par un appel direct. Ce que l'on croit interdit reste parfois grand ouvert côté données. Autre dette classique, et plus insidieuse : la même règle dupliquée à l'identique dans sept fichiers. La générer sept fois coûte quelques secondes. La repérer, la centraliser et garantir qu'elle ne se redupliquera pas relève du métier, pas de la génération.

6. La boucle client, de la remontée à la preuve de livraison

C'est ici que se trouve, à mon sens, le vrai tour de force du projet. Il ne consiste pas à coder vite. Il consiste à avoir fermé la boucle entre le besoin du cabinet et la preuve de sa livraison, sans jamais sortir de l'outil.

Tout commence dans l'application. Le cabinet formule ses demandes directement depuis HORALIO. Elles remontent dans un back-office d'arbitrage où chaque demande est traitée : acceptée avec un niveau de priorité, planifiée sur une version cible, mise en attente, marquée comme doublon, ou refusée avec un motif explicite. Le dépôt de code joue le rôle de pivot. À l'acceptation, un ticket est créé automatiquement, et sa fermeture fait repasser la demande en « livrée » côté client. L'assistance ne se contente pas de créer des tickets : elle surveille le dépôt, interprète chaque demande au regard du contexte propre au cabinet, puis prépare la planification avec les éléments requis, attendu, description, impacts connexes, urgence, criticité, et jusqu'à une recommandation d'arbitrage. L'arbitrage humain reste souverain, mais il reçoit un dossier déjà instruit.

Le cabinet voit en temps réel ce qui est en cours, ce qui est planifié, ce qui est écarté, et pourquoi. La traçabilité n'est pas un artefact interne réservé à l'équipe : c'est une information rendue au client, avec ses justifications. Résultat : une remontée du matin peut être arbitrée, développée, testée et mise en ligne dans la foulée. La vélocité n'est plus bridée par le cycle de développement. Elle est cadrée par le dernier garde-fou qu'on refuse de sacrifier, la validation humaine.

La clé de voûte : des jeux de tests contextualisés. L'assistance produit les jeux de données de recette qui reflètent les vrais cas du cabinet, dossiers réels, rôles réels, cas limites métier, ainsi que les tests qui verrouillent le noyau sensible. Sans cette génération contextualisée, la recette deviendrait le goulot d'étranglement. Avec elle, tester cesse d'être un frein et devient le socle de confiance qui autorise la vitesse.

Le flux, dans ses grandes lignes. Une anomalie ou un besoin détecté en recette interne devient un ticket tracé. L'assistance l'instruit au regard du contexte du cabinet, alimente un carnet de commandes priorisé et propose un séquencement. Un plan de livraison est déployé en préproduction, accompagné de supports de recette portant uniquement sur les développements concernés, que le cabinet valide ou amende sur son propre périmètre. L'intégration passe sous double contrôle automatisé, puis la mise en production est faite par un humain, souverain, non délégué. Suivent une page de livraison lisible pour le client et une surveillance des journaux.

Une dizaine de points de contrôle jalonnent cette chaîne, chacun réglé par des essais successifs. Le détail de ce réglage, c'est à dire ce qui est automatisé, ce qui ne doit jamais l'être, et où placer exactement les vérifications, constitue l'essentiel du savoir-faire. Il ne se transpose pas d'une organisation à l'autre sans être discuté. L'assurance qualité, poste habituellement le plus coûteux et le plus négligé d'un projet logiciel, devient ici industrialisée, contextualisée et continue, sans jamais retirer à l'humain la décision qui engage la production.

Un mot sur l'outillage. Un saut important s'est produit depuis le début de l'année, tant sur la capacité d'analyse contextuelle que sur l'orchestration. Autre bascule utile : la possibilité de déléguer certaines tâches à des modèles plus économiques, avec des livrables d'une qualité étonnante. On répartit la puissance là où elle est nécessaire, et la frugalité là où elle suffit. Quant au coût de cet outillage, souvent imaginé démesuré, il s'est limité à un abonnement du commerce. Rapporté à ce qui a été produit, il n'est pas significatif. Sur le maquettage, un poste entier a disparu du budget, celui des outils graphiques : le prototypage assisté a produit des maquettes proches à environ 90 % de la version finale.

7. La barrière de qualité, non négociable

Aucun envoi vers la branche principale sans trois feux verts : vérification des types à zéro erreur, suite de tests à 163 sur 163 passés, et construction du paquet en succès. La logique sensible (calculs de budget, cascade de taux, seuils d'alerte) est extraite en fonctions pures et testée. Le reste peut bouger, ce noyau non.

Ce point est contre-intuitif et mérite d'être appuyé : c'est précisément parce que le code est produit vite qu'il faut une barrière plus stricte, pas plus souple. La barrière est ce qui autorise la vitesse. Sans elle, la vitesse n'est qu'une dette contractée à découvert.

8. Sécurité

Le principe directeur : ce qui est interdit à l'écran doit être interdit côté serveur, et vérifié comme tel. Concrètement, quatre familles de mesures ont été appliquées et vérifiées avant la mise en production : une isolation stricte des données entre cabinets, portée par le modèle de données et non par l'interface ; une gestion des jetons et des accès temporaires reposant sur des mécanismes standards, avec expiration et révocation ; des garde-fous d'environnement empêchant la préproduction d'atteindre de vrais destinataires ; et une chaîne de sauvegardes chiffrées en région européenne, testée de bout en bout, avec rotation des accès après mise en ligne.

Les audits eux-mêmes ont été outillés. Des agents d'audit offensif open source ont été passés sur l'application pour sonder les points d'entrée avant la mise en production. L'assistance n'a pas seulement écrit le code, elle a aussi servi à l'attaquer pour le durcir. Plusieurs opérations d'infrastructure sensibles ont été volontairement repassées à l'humain. Une assistance automatisée ne doit pas détenir les clés de la production sans validation.

Le détail des mécanismes défensifs, nommage des champs d'isolation, algorithmes exacts, durées de validité, comportement des rapports partagés, n'est pas publié à dessein. Publier l'architecture défensive d'une application en production qui héberge les données de clients d'un cabinet d'audit reviendrait à en publier la carte.

9. Exploitation et souveraineté

C'est ici que se joue la promesse faite au cabinet. Une application livrée n'est rien si elle reste captive d'une plateforme qu'on ne maîtrise pas. Deux briques rendent HORALIO réellement possédable. La conteneurisation : l'application, ses dépendances et son environnement sont figés dans une image reproductible à l'identique, indépendante de la machine, déplaçable d'un serveur à l'autre. Et une plateforme de déploiement auto-hébergée, installée sur le serveur du cabinet, alternative souveraine aux plateformes commerciales. À chaque envoi de code, elle enchaîne migrations et construction, puis un déploiement progressif sans coupure. Tout le confort du déploiement moderne, sans confier ni le code ni les données à un tiers.

Les pièges qui ne s'inventent pas sont ceux qui coûtent des heures, et aucun n'est générable. Ne jamais conclure « déployé » d'après l'apparence : le seul marqueur fiable est l'empreinte de la version exposée par l'application elle-même. Et un déploiement progressif fait coexister deux versions pendant une minute environ, l'empreinte alternant entre les deux ; un script d'attente naïf conclut au succès dès la première réponse favorable, alors que la bascule n'est pas terminée. Une dizaine d'autres pièges du même ordre ont jalonné la mise en production, du voyant « succès » de l'orchestrateur qui ne dit rien de l'état réel, aux échecs d'authentification difficiles à diagnostiquer. Chacun a coûté du temps une fois, et une seule.

Et la mise en production n'est pas la fin. Sauvegardes chiffrées vers un stockage objet européen, testées de bout en bout. Surveillance de disponibilité hébergée hors du serveur surveillé, parce qu'un serveur ne peut pas signaler sa propre panne. Notifications d'incident. Procédure écrite de reprise. Le cabinet tient chaque maillon de la chaîne, du conteneur à la sauvegarde, sans dépendance à un grand fournisseur de nuage.

Ce métier a un nom : l'ingénieur déployé chez le client

Tout ce qui précède décrit une manière de travailler. Elle n'est pas de mon invention : c'est un modèle établi, nommé, et aujourd'hui massivement adopté par le secteur. Le Forward Deployed Engineer, ou FDE, que l'on peut rendre en français par ingénieur déployé chez le client.

Le rôle a été inventé et systématisé par Palantir, dont les premiers clients étaient des agences gouvernementales et de grandes institutions, c'est à dire des environnements où l'infrastructure est complexe, la conformité contraignante, et où aucun logiciel du commerce ne pouvait convenir tel quel. Plutôt que de livrer une licence et de laisser le client se débrouiller, l'entreprise déployait ses ingénieurs à l'intérieur, pour des mois, afin de construire les cas d'usage avec les équipes. Le modèle a longtemps été jugé trop coûteux et trop étrange pour être copié. Il ne l'est plus. OpenAI a monté son équipe en 2024, Anthropic a développé la sienne, rejoints par Databricks, Scale AI, Google DeepMind et d'autres. Les offres d'emploi pour ce poste ont progressé de plus de 800 % entre janvier et septembre 2025. Au printemps 2026, Anthropic et OpenAI ont chacun lancé une coentreprise de déploiement en entreprise chiffrée en milliards, entièrement construite autour de ce rôle.

Le trait distinctif est une responsabilité de bout en bout : celui qui cartographie le problème le premier jour est celui qui répond quand la production casse six mois plus tard. Cela exclut le passage de relais vers une équipe de support qui n'a rien conçu, et cela exclut le rôle d'intégrateur qui paramètre le produit d'un autre. On construit ce qui manque, et on en répond. Les seize jours ne sont pas la démonstration, ils en sont la conséquence : le modèle de données parlait déjà la langue du cabinet avant la première ligne de code, et la personne qui a tranché sur la refonte du contrôle d'accès était la même que celle qui répondrait de la production ensuite.

10. Économie de la méthode

Les contraintes économiques ont imposé la méthode, et non l'inverse. Un prix volontairement bas interdit l'infrastructure coûteuse et le développement à rallonge. La marge n'existe que dans la frugalité. D'où quatre règles qui ont toutes une traduction financière directe : un seul déploiement à la fois, ce qui évite les constructions inutiles ; une recette menée sur la préproduction déployée, contrainte transformée en avantage ; une mémoire persistante entre sessions d'assistance, qui économise la quasi-totalité du contexte rechargé à chaque reprise ; et une barrière de qualité passée en local, ce qui revient à payer la vérification une fois plutôt que trois fois en constructions ratées. La vitesse de l'assistance ne réduit les coûts que si la méthode est rationalisée. Sans cela, elle les déplace simplement vers la facture d'infrastructure.

11. L'équivalent en équipe humaine

C'est l'estimation la plus discutée, alors traitons l'objection avant qu'on ne la formule. Estimer une charge humaine à partir d'un nombre de lignes est une méthode contestée, et elle l'est davantage encore ici : le code assisté est en moyenne plus verbeux que le code écrit à la main. Compter les lignes surestime donc mécaniquement l'effort équivalent. L'ordre de grandeur ne repose pas sur le volume, mais sur la liste des livrables, dont chacun est vérifiable :

une application multi-locataires avec contrôle d'accès et isolation des données ;
un back-office d'administration livré simultanément (provisionnement, arbitrage des demandes, supervision) ;
une documentation fonctionnelle et une documentation technique ;
un cahier de tests spécifique au client ;
une fonction de recette contextualisée, section par section et rôle par rôle, intégrée au produit ;
un journal des livraisons et sa gestion ;
une chaîne d'exploitation complète, sauvegardes, surveillance, procédure de reprise.

Ce sont précisément ces à-côtés, jamais glamour, que les projets réels sacrifient presque toujours. Chiffrer ce périmètre à l'ancienne conduit, quelle que soit la méthode d'estimation retenue, à une équipe pluridisciplinaire de cinq à six personnes mobilisée plusieurs mois, soit de l'ordre de trente hommes-mois. Les huit rôles orchestrés (le terme d'agent recouvre ici des rôles distincts, tenus par une même personne s'appuyant sur une assistance spécialisée à chaque étape) : cadrage et analyse fonctionnelle, architecture, design et maquettage, développement, revue de code et sécurité, recette, livraison et exploitation, documentation.

Les ordres de grandeur, marché France, à ajuster selon le périmètre. En interne, une trentaine d'hommes-mois en masse salariale chargée conduit à environ 180 à 230 k€. En prestation, avec tarif journalier mixte, marge et coordination, plutôt 350 à 500 k€. HORALIO a été construit par un pilote expérimenté sur trois semaines, infrastructure mutualisée, abonnement d'assistance, pour une fraction de ces montants. L'écart n'est pas une remise commerciale, c'est un changement de nature. Le montant exact ne figure pas ici volontairement : il dépend trop du périmètre, et un chiffre isolé se retourne toujours contre celui qui le publie.

12. Du service loué au logiciel possédé

Un basculement de modèle s'est opéré. Non plus un service mutualisé, mais un serveur dédié au cabinet, où les données sont hébergées et pilotées en pleine maîtrise. La conteneurisation et le déploiement auto-hébergé sont exactement ce qui rend ce passage tangible plutôt que théorique. L'assistance a joué ici trois rôles simultanés : un transfert de compétence, puisque la logique de l'outil est explicite et maîtrisée ; un accélérateur, seize jours au lieu d'années d'itérations ; et un créateur de valeur, l'application cessant d'être une charge locative pour devenir un actif détenu.

La formule, sans ambiguïté. La propriété est le principe, pas une option. Le cabinet fait déployer l'application sur son propre serveur et en devient propriétaire, code et données compris. Une instance que nous hébergeons reste possible pour démarrer sans mobiliser d'infrastructure, mais elle est pensée dès l'origine comme réversible : la sortie est prévue, documentée, et ne dépend d'aucune autorisation de notre part. Un logiciel qu'on ne peut pas emporter n'est pas un logiciel qu'on possède, et une clause contractuelle ne remplace pas un artefact déplaçable.

13. La suite

L'évolution est tracée : embarquer sur le serveur dédié un modèle allégé, hébergé localement, pour faire naître un assistant qui travaille au plus près des données du cabinet. Modèle maîtrisé, hébergement souverain, données qui ne sortent pas. L'intelligence intégrée à l'actif, plutôt que louée à l'extérieur. D'autres briques suivront vraisemblablement, un planning des ressources, une paie simplifiée adossée au dispositif simplifié de l'organisme de recouvrement social. Chacune se greffe sur le socle existant.

14. La réserve honnête : et si le modèle économique de l'assistance changeait ?

Tout ce qui précède repose sur une condition que je ne maîtrise pas : la stabilité du modèle de facturation des fournisseurs de modèles. L'économie de ce projet tient à un abonnement forfaitaire, aujourd'hui largement subventionné par les levées de fonds du secteur. Si la facturation basculait vers une tarification à l'usage calée sur le coût réel de production, l'équation changerait pour tout le monde, y compris pour moi.

Ce n'est pas une hypothèse d'école, c'est en train de se produire. Le cas d'Anthropic sur son modèle le plus puissant, Fable 5, est instructif. Lancé début juin 2026, il a d'abord été suspendu quelques jours plus tard pour une raison sans rapport avec les prix, une restriction américaine à l'exportation liée à des inquiétudes sur des usages en cybersécurité, avant réouverture le 1er juillet. Puis, sur le volet tarifaire, l'arbitrage est tombé le 20 juillet : le modèle reste inclus sans date de fin dans les formules haut de gamme, à hauteur de la moitié des limites hebdomadaires, tandis que les formules d'entrée de gamme basculent vers des crédits d'usage payants. Autrement dit, la bascule vers l'usage a bien eu lieu, elle n'a pas été annulée, et elle frappe d'abord les petits comptes.

Pour un projet comme celui-ci, la conséquence est simple à énoncer : la frugalité méthodologique décrite plus haut n'est pas une coquetterie d'ingénieur. C'est une couverture.

15. Où est la survaleur

L'intelligence artificielle a réellement multiplié la vitesse. Mais soyons lucides sur l'endroit où se trouve la valeur. Beaucoup se trompent de combat. Résumer des courriels et produire des plans d'action, c'est sympathique, limité et coûteux. De très grandes entreprises font aujourd'hui marche arrière face à l'envolée des coûts. Distribuer des assistants conversationnels et obliger chacun à faire relire ses messages, c'est l'illusion de la transformation. La transformation réelle demande un travail chirurgical : identifier précisément où se trouvent les points d'amélioration organisationnelle et de démultiplication des marges. Cette hauteur de vue, la machine ne l'apporte pas. Ce sont les praticiens qui l'apportent, encore pour un temps.

Ce qui a fait tenir HORALIO, ce n'est pas la génération de code. C'est la méthode, et le jugement de savoir quand ne pas coder vite.

Concrètement : une barrière de qualité non négociable, des tests sur le noyau sensible, des règles gardées côté serveur, un seul déploiement à la fois, une vérification par l'empreinte et non par l'apparence, une recette qui pèse autant que le développement, et la décision de mise en production laissée à un humain.

HORALIO est en production, à l'adresse horalio.net. Environ 39 000 lignes, seize jours, huit rôles orchestrés, un audit de sécurité passé avant mise en ligne. Et, pour un cabinet, le début de la propriété pleine et entière de son outil.

L'intelligence artificielle ne remplace pas l'expertise, l'expérience, la mémoire, l'intuition. Elle les amplifie de façon vertigineuse. Mais elle démultiplie tout aussi vite les erreurs, les impasses et les boucles de celui qui n'en a pas.

Questions fréquentes

Comment un logiciel métier a-t-il pu être mis en production en seize jours ?

Ce qui a été rare n'est pas la génération de code mais la discipline qui l'a dirigée : un modèle de données qui parlait déjà la langue du cabinet, une barrière de qualité stricte, et une recette contextualisée aussi coûteuse que le développement lui-même.

Que possède réellement le cabinet ?

Au-delà du code et des données, l'actif durable est le modèle explicite et formalisé de son propre travail : sa façon de concevoir une mission, un temps déclarable, une règle de confidentialité. Le code qui l'exprime aujourd'hui pourrait être régénéré en quelques jours ; l'inverse n'est pas vrai.

Pourquoi une règle métier doit-elle être gardée côté serveur ?

Parce qu'une interdiction affichée seulement à l'écran se contourne par un appel direct. Une règle métier non gardée côté serveur n'existe pas. L'isolation des données entre cabinets et le contrôle des accès sont portés par le modèle, pas par l'interface.

Retour d'expérience technique. HORALIO, un logiciel métier possédé, en production sur horalio.net.

← Tous les articles Nous contacter →

← News

Field report · Technical

A business application in sixteen days, and the safeguards that make it defensible.

by José Vazquez

7 August 2026 · See HORALIO in production →

An audit and accounting firm equipped itself with a custom time-tracking application, tested, documented, and in production, in sixteen days. The application is live and belongs to the firm. It runs at horalio.net. What was rare in this project was not the code generation. It was the discipline that made it possible to dare put it into production.

Here is the technical field report, in two parts: how you build, then what that changes. What is rare is not the speed, it is the judgment that steers it.

1. What speed displaces

When a machine produces code faster than a human can read it back, the nature of the risk changes. It no longer lies in the difficulty of writing, it lies in silent drift: a convention that erodes from one session to the next, an architectural decision forgotten and then contradicted three days later, a business rule stated on screen but not in the right place, a red test worked around because someone was in a hurry.

None of this is spectacular. That is exactly why it is dangerous. An assisted project that fails does not explode, it rots.

Everything that follows has a single purpose: to make drift impossible without anyone noticing. That, and not the generation, is where the craft lies.

2. The origin and the real scope

An audit and accounting firm wants to make its internal processes more agile and to equip itself with an "ultra-simplified" time-tracking application. The entire design rested on that word, and it is worth pausing on, because it is misleading. The ultra-simple is multidimensional and costly to produce. It is a result, not a feature: what remains once every trade-off has been settled. A feature-rich piece of software is one that has settled nothing and has shifted every decision onto the user, disguising it as configuration freedom. It is by far the easier thing to build.

Five distinct dimensions, none reducible to the others: simple to enter (number of gestures, sensible defaults, no navigation), simple to learn (a falsifiable promise: either a new employee gets there on their own, or the promise is false), simple to adopt (the tool speaks the language of the house, there is nothing to translate), simple to read (the manager who consults the data does not have the needs of the employee who enters it, and simplicity of reading does not follow from simplicity of entry), simple to maintain (fewer options, fewer states, fewer combinations to test).

Two engineering consequences govern everything else. First, simplicity reaches all the way up to the data model. It is not settled in the interface. If the structure conceives the client's world badly, no screen can be simple: you will have to ask the user to compensate by hand for what the model cannot represent. A complicated interface is almost always the symptom of a model that thinks crookedly. Second, assisted generation makes simplicity harder to hold, not easier. As long as adding a feature was expensive, the budget arbitrated in our place. When adding becomes almost free, that safeguard disappears: the machine will add anything you ask, immediately, cleanly, without ever objecting. Simplicity stops being a budgetary constraint and becomes a pure matter of judgment.

Two further requirements complete the brief: very strong customization capabilities (mission types, labels, rules, files), and the building of an asset for the company. What is customized is not a set of options offered to the user, it is the structure itself, arbitrated before the first line of code. And the real seam is not the data entry, it is the data it produces: internal traceability for steering missions, transparency toward the client without exposing costs or margins, and the reliability of regulatory reporting to the profession's supervisory body, where the quality of the declarations depends directly on the reliability of the declared time.

The numbers, to set the scene:

Versioned lines: roughly 39,100.
Commits in sixteen days: 269 (first on July 7, production release on the 21st).
Interface components: 122.
Automated tests: 163 at the time of going live.
Orchestrated assistance roles: 8.
On the server side: 14 server-action modules, 10 application routes, 25 modules of pure business logic, on a relational base of 805 schema lines and 23 migrations.

The scope, and what is always underestimated. The interface (roughly 23,400 lines, 122 components) covers data entry, dashboards, reports, configuration, a six-step onboarding flow, and a unified mobile version. It is the part that assistance generates the fastest, and the one where "it looks finished" is most deceptive. The server carries the essential: isolation between firms, access control, budget calculations. Invisible, but it is the real product. Acceptance testing is the most underestimated part, and it cost as much as the development: 163 automated tests, manual passes running up to fifty-five checkpoints at once, four data sets reflecting the real files, and a systematic browser acceptance pass before every delivery.

Development on the fly, without acceptance testing, is not fast development. It is amputated development.

3. Framing: assistance accelerates, it does not decide

Assistance excels at producing a specification, usage scenarios, and a data model in a few hours. The limit arrives quickly, and it always arrives at the same place: at the first change that touches the structure.

The firm asks that several employees be able to work on the same file. In the database, the assignment rested on a simple relationship, one employee for one file. Doing it properly meant a join table and, in its wake, a rework of the access control. Development on the fly would have hacked together a workaround overnight. The right decision was to pause, to arbitrate with the client, and to treat the request as a project in its own right.

Experience is knowing what you do not code right away.

4. The model of the client's world

This decision deserves a pause, because it touches the true object of this project and the only asset that is hard to reproduce. The accepted term is the ontology. I will use it sparingly, because it scares people off and makes them think of theory. It refers to something very concrete: the objects an organization talks about, the rules that govern them, and the order in which those rules apply. Its nouns, its verbs, its grammar.

It is not the database schema. The schema is one implementation of it, at a given moment, in a given technology. You can implement a false model perfectly, and that is even the most frequent case: normalized, indexed, constrained, and describing a world that is not the client's.

An example drawn from this project. The cascade of rates applied to entered time follows a strict order of specificity, from the most particular to the most general: a rate set for an employee on a given project prevails over a project rate, which prevails over a client rate, which prevails over the firm's rate. Technically, it is a resolution function of a few lines. Conceptually, it is an assertion about the world: this firm holds that the particular always prevails over the general when it comes to valuation. Another firm could decide the opposite. No generic software ever asks that question, and that is why so many users correct their reports by hand after extraction. This rule is extracted into a pure function and tested, precisely because it is not technical. The code can change, the rule cannot.

The first framing move: ask for the parallel files. The fastest way to detect a disagreement between the installed model and the real business is to look at what orbits the official software. Hand-kept spreadsheets that nobody commissioned, free-text fields filled with codes passed on orally, naming conventions that carry structured information the tool cannot store, a double entry that no one contests anymore because it predates everyone.

These artifacts are not indiscipline. They are the fragments of the real business, expelled from the system because it did not know how to accommodate them, and reinjected by hand by people who know what they are talking about. Each one is a free specification, already written, waiting to be read. It is the first thing I ask for on arrival, before any discussion of needs: show me your parallel files. An hour spent on them is worth a day of workshops.

Why this cannot be gathered in writing. The essential is tacit. Ask a partner what a mission is: you will get a clear definition, in one sentence, immediately. Then watch the firm work, and you will find several categories of missions with distinct behavior, some of which they would never have thought to mention because they go without saying. It is neither vagueness nor withholding. It is the nature of professional knowledge: what one masters best is what one spells out least. The technique that works is counter-intuitive: propose a deliberately approximate formulation and wait for the correction. A displayed and slightly wrong model triggers, in thirty seconds, a "no, not quite, actually it's more like..." that three requirements-gathering meetings would not have produced. That is the technical, and not the commercial, justification for working on site.

An operational criterion, transposable as of tomorrow. A request comes in. Before estimating it, ask a single question: how far does it propagate? If it stays on one screen, it is a feature. You estimate it, you plan it, you deliver it. If it touches access control, reports, and history all at once, it is not a feature. It is the model that was wrong, and it becomes a project. The shared-files episode is the exact illustration: "several employees on one file" presented itself as a field to duplicate, two hours of work. In reality the system took for granted that a file belongs to one employee, and the confidentiality rules derived from that ownership.

Propagation is the signature. And that is precisely where undirected assisted development produces its worst result. The machine knows perfectly well how to create a join table, migrate the data, and adapt the screens. It does not know that in doing so it has just silently invalidated a security model. The code will compile, the existing tests will pass, and the flaw will wait for acceptance testing. Or worse, production.

What is really owned. We say the firm owns its software. That is true of the code and the data. But the durable value is not there. The code has a life expectancy of a few years, and assisted generation will make its replacement almost painless. On the other hand, the way an audit firm conceives of a mission, a billable hour, a confidentiality rule toward a fellow professional, evolves on the scale of a decade. What the firm really owns is the explicit, formalized model of its own work. The code that expresses it today could be regenerated in a few days from that model. The reverse is not true. The technical stack of this project can be copied in an afternoon. The understanding of how a statutory auditor justifies their time to their supervisory body cannot be copied, because it is written down nowhere.

5. Architecture and business rules, where generation becomes dangerous

The core of the product is confidentiality rules: who sees what, and above all who does not see what. The trap of quickly generated code is always the same: the rule is placed where it shows, that is, in the interface, and nowhere else. A check found during acceptance testing illustrated it perfectly: an entry prohibition correctly displayed on screen, but absent on the server side, and therefore bypassable through a direct call.

A business rule not guarded on the server side does not exist.

The principle seems elementary, and yet it is not always respected by long-installed market software, where a check displayed on screen can be bypassed through a direct call. What one believes to be forbidden sometimes stays wide open on the data side. Another classic and more insidious debt: the same rule duplicated identically across seven files. Generating it seven times costs a few seconds. Spotting it, centralizing it, and guaranteeing it will not re-duplicate is a matter of craft, not of generation.

6. The client loop, from request to proof of delivery

This, to my mind, is where the real feat of the project lies. It does not consist of coding fast. It consists of having closed the loop between the firm's need and the proof of its delivery, without ever leaving the tool.

It all starts in the application. The firm formulates its requests directly from HORALIO. They flow up into an arbitration back-office where each request is handled: accepted with a priority level, planned on a target version, put on hold, marked as a duplicate, or refused with an explicit reason. The code repository plays the pivotal role. On acceptance, a ticket is created automatically, and its closure moves the request back to "delivered" on the client side. Assistance does not merely create tickets: it watches the repository, interprets each request in light of the firm's own context, then prepares the planning with the required elements, expected result, description, related impacts, urgency, criticality, and even an arbitration recommendation. Human arbitration remains sovereign, but it receives a file that has already been worked up.

The firm sees in real time what is in progress, what is planned, what is set aside, and why. Traceability is not an internal artifact reserved for the team: it is information returned to the client, with its justifications. The result: a morning request can be arbitrated, developed, tested, and put online in the same stride. Velocity is no longer throttled by the development cycle. It is framed by the last safeguard one refuses to sacrifice, human validation.

The keystone: contextualized test data sets. Assistance produces the acceptance-testing data sets that reflect the firm's real cases, real files, real roles, business edge cases, as well as the tests that lock down the sensitive core. Without this contextualized generation, acceptance testing would become the bottleneck. With it, testing stops being a brake and becomes the bedrock of trust that permits speed.

The flow, in broad strokes. An anomaly or a need detected in internal acceptance testing becomes a traced ticket. Assistance works it up in light of the firm's context, feeds a prioritized order book, and proposes a sequencing. A delivery plan is deployed to pre-production, accompanied by acceptance-testing materials bearing only on the developments concerned, which the firm validates or amends on its own scope. Integration passes under a double automated control, then the production release is done by a human, sovereign, not delegated. Then follow a client-readable delivery page and log monitoring.

A dozen or so checkpoints punctuate this chain, each tuned through successive trials. The detail of that tuning, that is, what is automated, what must never be, and exactly where to place the checks, constitutes the essence of the craft. It does not transpose from one organization to another without being discussed. Quality assurance, usually the most costly and most neglected item of a software project, becomes here industrialized, contextualized, and continuous, without ever taking away from the human the decision that commits production.

A word on the tooling. An important leap has occurred since the start of the year, both in the capacity for contextual analysis and in orchestration. Another useful shift: the ability to delegate certain tasks to more economical models, with deliverables of surprising quality. You allocate power where it is needed, and frugality where it suffices. As for the cost of this tooling, often imagined to be enormous, it was limited to an off-the-shelf subscription. Set against what was produced, it is not significant. On the mock-up front, an entire budget line disappeared, that of graphic design tools: assisted prototyping produced mock-ups roughly 90% close to the final version.

7. The quality gate, non-negotiable

No push to the main branch without three green lights: type checking at zero errors, test suite at 163 out of 163 passing, and a successful package build. The sensitive logic (budget calculations, rate cascade, alert thresholds) is extracted into pure functions and tested. The rest can move, this core cannot.

This point is counter-intuitive and deserves to be stressed: it is precisely because the code is produced fast that the gate must be stricter, not more lenient. The gate is what permits the speed. Without it, speed is merely a debt taken out on an overdraft.

8. Security

The guiding principle: what is forbidden on screen must be forbidden on the server side, and verified as such. Concretely, four families of measures were applied and verified before going live: a strict isolation of data between firms, carried by the data model and not by the interface; a management of tokens and temporary access relying on standard mechanisms, with expiration and revocation; environment safeguards preventing pre-production from reaching real recipients; and a chain of encrypted backups in a European region, tested end to end, with rotation of access credentials after going online.

The audits themselves were tooled. Open-source offensive audit agents were run against the application to probe the entry points before the production release. Assistance did not only write the code, it also served to attack it in order to harden it. Several sensitive infrastructure operations were deliberately handed back to a human. Automated assistance must not hold the keys to production without validation.

The detail of the defensive mechanisms, the naming of the isolation fields, the exact algorithms, the validity durations, the behavior of shared reports, is not published by design. Publishing the defensive architecture of a production application that hosts the data of an audit firm's clients would amount to publishing its map.

9. Operations and sovereignty

This is where the promise made to the firm is decided. A delivered application is nothing if it stays captive to a platform one does not control. Two building blocks make HORALIO truly ownable. Containerization: the application, its dependencies, and its environment are frozen into an image reproducible identically, independent of the machine, movable from one server to another. And a self-hosted deployment platform, installed on the firm's server, a sovereign alternative to commercial platforms. On every code push, it chains migrations and build, then a progressive deployment without downtime. All the comfort of modern deployment, without entrusting either the code or the data to a third party.

The pitfalls you cannot make up are the ones that cost hours, and none of them is generable. Never conclude "deployed" from appearances: the only reliable marker is the fingerprint of the version exposed by the application itself. And a progressive deployment makes two versions coexist for about a minute, the fingerprint alternating between the two; a naive waiting script concludes success at the first favorable response, while the switchover is not yet complete. A dozen other pitfalls of the same kind punctuated the production release, from the orchestrator's "success" light that says nothing of the real state, to authentication failures that are hard to diagnose. Each one cost time once, and once only.

And the production release is not the end. Encrypted backups to European object storage, tested end to end. Availability monitoring hosted off the monitored server, because a server cannot report its own outage. Incident notifications. A written recovery procedure. The firm holds every link in the chain, from the container to the backup, with no dependence on a large cloud provider.

This craft has a name: the Forward Deployed Engineer

Everything above describes a way of working. It is not my invention: it is an established, named model, and today massively adopted by the sector. The Forward Deployed Engineer, or FDE.

The role was invented and systematized by Palantir, whose first clients were government agencies and large institutions, that is, environments where the infrastructure is complex, compliance is demanding, and no off-the-shelf software could fit as is. Rather than shipping a license and leaving the client to fend for themselves, the company deployed its engineers inside, for months, to build the use cases with the teams. The model was long judged too costly and too strange to be copied. It is no longer. OpenAI built its team in 2024, Anthropic developed its own, joined by Databricks, Scale AI, Google DeepMind, and others. Job postings for this position grew by more than 800% between January and September 2025. In the spring of 2026, Anthropic and OpenAI each launched an enterprise deployment joint venture valued in the billions, built entirely around this role.

The distinctive trait is end-to-end responsibility: the person who maps the problem on day one is the one who answers when production breaks six months later. That excludes the handoff to a support team that designed nothing, and it excludes the role of an integrator who configures someone else's product. You build what is missing, and you answer for it. The sixteen days are not the demonstration, they are its consequence: the data model already spoke the firm's language before the first line of code, and the person who made the call on reworking the access control was the same one who would answer for production afterward.

10. The economics of the method

Economic constraints imposed the method, not the other way around. A deliberately low price rules out costly infrastructure and open-ended development. Margin exists only in frugality. Hence four rules that all have a direct financial translation: a single deployment at a time, which avoids useless builds; acceptance testing carried out on the deployed pre-production, a constraint turned into an advantage; a persistent memory between assistance sessions, which saves almost all of the context reloaded at each resumption; and a quality gate passed locally, which amounts to paying for verification once rather than three times over in failed builds. The speed of assistance reduces costs only if the method is streamlined. Without that, it simply displaces them onto the infrastructure bill.

11. The human-team equivalent

This is the most contested estimate, so let us handle the objection before it is raised. Estimating a human workload from a line count is a disputed method, and it is more so here: assisted code is on average more verbose than hand-written code. Counting lines therefore mechanically overestimates the equivalent effort. The order of magnitude does not rest on volume, but on the list of deliverables, each of which is verifiable:

a multi-tenant application with access control and data isolation;
an administration back-office delivered simultaneously (provisioning, request arbitration, supervision);
functional documentation and technical documentation;
a client-specific test book;
a contextualized acceptance-testing feature, section by section and role by role, integrated into the product;
a delivery log and its management;
a complete operations chain, backups, monitoring, recovery procedure.

It is precisely these unglamorous extras that real projects almost always sacrifice. Costing this scope the old-fashioned way leads, whatever estimation method is chosen, to a cross-functional team of five to six people mobilized for several months, on the order of thirty person-months. The eight orchestrated roles (the term "agent" here covers distinct roles, held by a single person relying on specialized assistance at each step): framing and functional analysis, architecture, design and mock-up, development, code review and security, acceptance testing, delivery and operations, documentation.

The orders of magnitude, French market, to be adjusted according to scope. In-house, some thirty person-months in loaded payroll leads to roughly €180k to €230k. As a service engagement, with a mixed daily rate, margin, and coordination, more like €350k to €500k. HORALIO was built by an experienced lead over three weeks, on shared infrastructure, an assistance subscription, for a fraction of those amounts. The gap is not a commercial discount, it is a change in nature. The exact amount is deliberately not given here: it depends too much on scope, and an isolated figure always turns against whoever publishes it.

12. From rented service to owned software

A shift in model has taken place. No longer a shared service, but a server dedicated to the firm, where the data is hosted and steered in full control. Containerization and self-hosted deployment are exactly what makes this transition tangible rather than theoretical. Assistance played three roles here at once: a transfer of competence, since the tool's logic is explicit and mastered; an accelerator, sixteen days instead of years of iterations; and a creator of value, the application ceasing to be a rental charge and becoming an owned asset.

The formula, without ambiguity. Ownership is the principle, not an option. The firm has the application deployed on its own server and becomes the owner of it, code and data included. An instance we host remains possible in order to start without mobilizing infrastructure, but it is designed from the outset as reversible: the exit is planned, documented, and depends on no authorization from us. Software you cannot take with you is not software you own, and a contractual clause is no substitute for a movable artifact.

13. What comes next

The path forward is mapped: to bring aboard the dedicated server a lightweight model, hosted locally, to give rise to an assistant that works as close as possible to the firm's data. A mastered model, sovereign hosting, data that does not leave. Intelligence built into the asset, rather than rented from the outside. Other building blocks will likely follow, a resource planner, a simplified payroll leaning on the simplified scheme of the social-security collection body. Each grafts onto the existing base.

14. The honest reservation: what if the economics of assistance changed?

Everything above rests on a condition I do not control: the stability of the model providers' billing. The economics of this project rests on a flat-rate subscription, today largely subsidized by the sector's fundraising. If billing were to shift toward usage-based pricing aligned with the real cost of production, the equation would change for everyone, including for me.

This is not a textbook hypothesis, it is happening. The case of Anthropic with its most powerful model, Fable 5, is instructive. Launched in early June 2026, it was first suspended a few days later for a reason unrelated to pricing, a US export restriction tied to concerns about cybersecurity uses, before reopening on July 1. Then, on the pricing front, the ruling came on July 20: the model stays included with no end date in the top-tier plans, up to half of the weekly limits, while the entry-level plans shift toward paid usage credits. In other words, the shift to usage did happen, it was not cancelled, and it hits the small accounts first.

For a project like this one, the consequence is simple to state: the methodological frugality described above is not an engineer's affectation. It is a hedge.

15. Where the surplus value is

Artificial intelligence has genuinely multiplied speed. But let us be clear-eyed about where the value lies. Many are fighting the wrong battle. Summarizing emails and producing action plans is nice, limited, and costly. Very large companies are now backpedaling in the face of soaring costs. Distributing conversational assistants and forcing everyone to have their messages proofread is the illusion of transformation. Real transformation demands surgical work: identifying precisely where the points of organizational improvement and margin multiplication lie. That elevation of view, the machine does not bring. It is the practitioners who bring it, for a while yet.

What held HORALIO together was not the code generation. It was the method, and the judgment to know when not to code fast.

Concretely: a non-negotiable quality gate, tests on the sensitive core, rules guarded on the server side, a single deployment at a time, verification by fingerprint and not by appearance, acceptance testing that weighs as much as the development, and the production-release decision left to a human.

HORALIO is in production, at horalio.net. Roughly 39,000 lines, sixteen days, eight orchestrated roles, a security audit passed before going online. And, for a firm, the beginning of full and complete ownership of its tool.

Artificial intelligence does not replace expertise, experience, memory, intuition. It amplifies them dizzyingly. But it multiplies just as fast the mistakes, the dead ends, and the loops of whoever has none.

Frequently asked questions

How could a business application go to production in sixteen days?

What was rare was not code generation but the discipline that steered it: a data model that already spoke the firm's language, a strict quality gate, and contextualized acceptance testing as costly as the development itself.

What does the firm actually own?

Beyond the code and the data, the lasting asset is the explicit, formalized model of its own work: how it defines an engagement, a billable time, a confidentiality rule. The code expressing it today could be regenerated in a few days; the reverse is not true.

Why must a business rule be enforced on the server?

Because a restriction shown only on screen can be bypassed by a direct call. A business rule not enforced on the server does not exist. Data isolation between firms and access control are carried by the model, not by the interface.

Technical field report. HORALIO, an owned business application, in production at horalio.net.

← All articles Contact us →

← News

Retorno de experiencia · Técnico

Un software de gestión en dieciséis días, y las salvaguardas que lo hacen defendible.

por José Vazquez

7 de agosto de 2026 · Ver HORALIO en producción →

Un despacho de auditoría y contabilidad se dotó de un software de seguimiento del tiempo, a medida, probado, documentado, en producción, en dieciséis días. La aplicación está en servicio y le pertenece. Funciona en la dirección horalio.net. Lo que fue raro en este proyecto no es la generación de código. Es la disciplina que permitió atreverse a ponerlo en producción.

He aquí el retorno de experiencia técnico, en dos partes: cómo se construye, y luego lo que eso cambia. Lo raro no es la velocidad, es el criterio que la dirige.

1. Lo que la velocidad desplaza

Cuando una máquina produce código más rápido de lo que un humano lo relee, el riesgo cambia de naturaleza. Ya no está en la dificultad de escribir, está en la deriva silenciosa: una convención que se desmorona de una sesión a otra, una decisión de arquitectura olvidada y luego contradicha tres días después, una regla de negocio planteada en la pantalla pero no en el lugar correcto, una prueba en rojo esquivada porque hay prisa.

Nada de esto es espectacular. Es exactamente por esa razón que es peligroso. Un proyecto asistido que fracasa no explota, se pudre.

Todo lo que sigue tiene un solo objeto: hacer imposible la deriva sin que uno se dé cuenta. Eso, y no la generación, es lo que constituye el saber hacer.

2. El origen y el perímetro real

Un despacho de auditoría y contabilidad quiere agilizar sus procesos internos y dotarse de un software de seguimiento del tiempo «ultra simplificado». Todo el diseño se apoyó en esa palabra, y vale la pena detenerse en ella, porque es engañosa. Lo ultra simple es multidimensional y costoso de producir. Es un resultado, no una característica: lo que queda una vez zanjados todos los arbitrajes. Un software rico es un software que no ha zanjado nada y que ha trasladado cada decisión al usuario, disfrazándola de libertad de configuración. Es muchísimo más fácil de construir.

Cinco dimensiones distintas, que no se reducen unas a otras: simple de capturar (número de gestos, valores por defecto acertados, ausencia de navegación), simple de aprender (promesa falsable: o bien un nuevo colaborador lo logra solo, o bien es falsa), simple de adoptar (la herramienta habla el vocabulario de la casa, no hay nada que traducir), simple de leer (el responsable que consulta no tiene las necesidades del colaborador que captura, y la simplicidad de la lectura no se deduce de la de la captura), simple de mantener (menos opciones, menos estados, menos combinaciones que probar).

Dos consecuencias de ingeniería mandan sobre todo lo demás. Primero, la simplicidad se remonta hasta el modelo de datos. No se juega en la interfaz. Si la estructura concibe mal el mundo del cliente, ninguna pantalla podrá ser simple: habrá que pedirle al usuario que compense a mano lo que el modelo no sabe representar. Una interfaz complicada es casi siempre el síntoma de un modelo que piensa torcido. Después, la generación asistida hace la simplicidad más difícil de sostener, no más fácil. Mientras añadir una función costaba caro, el presupuesto arbitraba en nuestro lugar. Cuando añadir se vuelve casi gratuito, ese salvavidas desaparece: la máquina añadirá todo lo que se le pida, de inmediato, de forma limpia, sin objetar jamás. La simplicidad deja de ser una restricción presupuestaria para convertirse en un puro asunto de criterio.

Otras dos exigencias completan el encargo: unas muy fuertes capacidades de personalización (tipos de misiones, etiquetas, reglas, expedientes) y la constitución de un activo para la empresa. Lo que se personaliza no es un juego de opciones ofrecido al usuario, es la estructura misma, arbitrada antes de la primera línea de código. Y el verdadero yacimiento no es la captura, es el dato que produce: trazabilidad interna para el pilotaje de las misiones, transparencia frente al cliente sin exponer costes ni márgenes, y fiabilización de los reportes regulatorios ante la supervisión de la profesión, donde la calidad de las declaraciones depende directamente de la fiabilidad de los tiempos declarados.

Las cifras, para situar:

Líneas versionadas: unas 39.100.
Commits en dieciséis días: 269 (el primero el 7 de julio, puesta en producción el 21).
Componentes de interfaz: 122.
Pruebas automatizadas: 163 en el momento de la puesta en producción.
Roles de asistencia orquestados: 8.
Del lado del servidor: 14 módulos de acciones de servidor, 10 rutas de aplicación, 25 módulos de lógica de negocio pura, sobre una base relacional de 805 líneas de esquema y 23 migraciones.

El perímetro, y lo que siempre se subestima. La interfaz (unas 23.400 líneas, 122 componentes) cubre la captura, los cuadros de mando, los informes, la parametrización, un recorrido de bienvenida en seis etapas y una versión móvil unificada. Es la parte que la asistencia genera más rápido, y aquella en la que «parece terminado» engaña más. El servidor carga con lo esencial: aislamiento entre despachos, control de accesos, cálculos de presupuesto. Invisible, pero es el verdadero producto. Las pruebas de aceptación son la parte más subestimada, y costaron tanto como el desarrollo: 163 pruebas automatizadas, pasadas manuales que llegan hasta cincuenta y cinco puntos de control de una vez, cuatro juegos de datos que reflejan los expedientes reales, y un control de calidad en navegador sistemático antes de cada entrega.

El desarrollo sobre la marcha, sin pruebas de aceptación, no es desarrollo rápido. Es desarrollo amputado.

3. Encuadre: la asistencia acelera, no decide

La asistencia sobresale en producir un pliego de condiciones, escenarios de uso y un modelo de datos en unas horas. El límite llega pronto, y llega siempre en el mismo sitio: en el primer cambio que toca la estructura.

El despacho pide que varios colaboradores puedan intervenir sobre un mismo expediente. En la base, la asignación reposaba sobre una relación simple, un colaborador por expediente. Hacerlo bien suponía una tabla de enlace y, acto seguido, una reelaboración del control de acceso. Un desarrollo sobre la marcha habría improvisado un apaño durante la noche. La decisión correcta fue suspender, arbitrar con el cliente y tratar la petición como un proyecto de fondo.

La experiencia es saber lo que no se codifica de inmediato.

4. El modelo del mundo del cliente

Esta decisión merece que nos detengamos, porque toca el verdadero objeto de este proyecto y el único activo difícilmente reproducible. El término consagrado es la ontología. Lo emplearé poco, porque ahuyenta y hace creer que hay teoría. Se trata de algo muy concreto: los objetos de los que habla una organización, las reglas que los gobiernan, y el orden en el que esas reglas se aplican. Sus nombres, sus verbos, su gramática.

No es el esquema de la base de datos. El esquema es una implementación de ella, en un instante dado, en una tecnología dada. Se puede implementar a la perfección un modelo falso, y es incluso el caso más frecuente: normalizado, indexado, restringido, y describiendo un mundo que no es el del cliente.

Un ejemplo sacado de este proyecto. La cascada de tarifas aplicada a los tiempos capturados sigue un orden de especificidad estricto, de lo más particular a lo más general: una tarifa fijada para un colaborador en un proyecto dado prevalece sobre una tarifa de proyecto, que prevalece sobre una tarifa de cliente, que prevalece sobre la tarifa del despacho. Técnicamente, es una función de resolución de unas pocas líneas. Conceptualmente, es una afirmación sobre el mundo: este despacho sostiene que lo particular prima siempre sobre lo general en materia de valorización. Otro despacho podría decidir lo contrario. Ningún software genérico plantea jamás esta pregunta, y es por eso que tantos usuarios corrigen sus estados a mano tras la extracción. Esta regla se extrae en función pura y se prueba, precisamente porque no es técnica. El código puede cambiar, la regla no.

El primer gesto de encuadre: pedir los ficheros paralelos. La manera más rápida de detectar un desacuerdo entre el modelo instalado y el oficio real es mirar lo que gravita alrededor del software oficial. Hojas de cálculo llevadas a mano que nadie encargó, campos libres rellenos de códigos transmitidos de palabra, convenciones de nomenclatura que portan una información estructurada que la herramienta no sabe almacenar, una doble captura que ya nadie discute porque es anterior a todos.

Estos artefactos no son indisciplina. Son los fragmentos del oficio real, expulsados del sistema porque no sabía acogerlos, y reinyectados a mano por gente que sabe de lo que habla. Cada uno es una especificación gratuita, ya redactada, que espera ser leída. Es lo primero que pido al llegar, antes de toda discusión de necesidades: enséñenme sus ficheros paralelos. Una hora encima de ellos vale una jornada de taller.

Por qué esto no se recoge por escrito. Lo esencial es tácito. Pregunte a un socio qué es una misión: obtendrá una definición clara, en una frase, de inmediato. Observe luego trabajar al despacho, y encontrará varias categorías de misiones con comportamiento distinto, algunas de las cuales nunca se le habría ocurrido mencionar porque se dan por sentadas. No es imprecisión ni retención. Es la naturaleza del saber profesional: lo que mejor se domina es lo que menos se explicita. La técnica que funciona es contraintuitiva: proponer una formulación deliberadamente aproximada y esperar la corrección. Un modelo mostrado y ligeramente falso desencadena en treinta segundos un «no, no del todo, en realidad es más bien...» que tres reuniones de recogida no habrían producido. Es la justificación técnica, y no comercial, del trabajo sobre el terreno.

Un criterio operativo, trasladable desde mañana. Llega una petición. Antes de estimarla, plantee una sola pregunta: ¿hasta dónde se propaga? Si se queda en una pantalla, es una funcionalidad. Se estima, se planifica, se entrega. Si toca a la vez el control de acceso, los informes y el histórico, no es una funcionalidad. Es el modelo que estaba mal, y eso se convierte en un proyecto de fondo. El episodio de los expedientes compartidos es la ilustración exacta: «varios colaboradores sobre un expediente» se presentaba como un campo que duplicar, dos horas de trabajo. En realidad el sistema daba por sentado que un expediente pertenece a un colaborador, y las reglas de confidencialidad derivaban de esa pertenencia.

La propagación es la firma. Y es precisamente ahí donde un desarrollo asistido no dirigido produce su peor resultado. La máquina sabe perfectamente crear una tabla de enlace, migrar los datos y adaptar las pantallas. No sabe que, al hacerlo, acaba de invalidar silenciosamente un modelo de seguridad. El código compilará, las pruebas existentes pasarán, y la falla esperará al control de calidad. O peor, a la producción.

Lo que realmente se posee. Decimos que el despacho posee su software. Es cierto del código y de los datos. Pero el valor duradero no está ahí. El código tiene una esperanza de vida de unos pocos años, y la generación asistida hará su reemplazo casi indoloro. En cambio, la manera en que un despacho de auditoría concibe una misión, un tiempo declarable, una regla de confidencialidad frente a un colega, evoluciona a escala de una década. Lo que el despacho posee realmente es el modelo explícito y formalizado de su propio trabajo. El código que lo expresa hoy podría regenerarse en unos días a partir de ese modelo. Lo inverso no es cierto. La pila técnica de este proyecto se copia en una tarde. La comprensión de la forma en que un auditor de cuentas justifica su tiempo ante su supervisión no se copia, porque no está escrita en ninguna parte.

5. Arquitectura y reglas de negocio, ahí donde la generación se vuelve peligrosa

El núcleo del producto son reglas de confidencialidad: quién ve qué, y sobre todo quién no ve qué. La trampa del código generado deprisa es siempre la misma: la regla se plantea donde se ve, es decir en la interfaz, y en ningún otro sitio. Un control constatado en las pruebas de aceptación lo ilustraba a la perfección: una prohibición de captura correctamente mostrada en la pantalla, pero ausente del lado del servidor, y por tanto esquivable mediante una llamada directa.

Una regla de negocio no protegida del lado del servidor no existe.

El principio parece elemental, y sin embargo no siempre lo respetan softwares del mercado instalados desde hace tiempo, donde un control mostrado en la pantalla se esquiva mediante una llamada directa. Lo que se cree prohibido queda a veces de par en par abierto del lado de los datos. Otra deuda clásica, y más insidiosa: la misma regla duplicada idéntica en siete ficheros. Generarla siete veces cuesta unos segundos. Detectarla, centralizarla y garantizar que no se volverá a duplicar es cuestión de oficio, no de generación.

6. El bucle con el cliente, de la petición a la prueba de entrega

Es aquí donde se encuentra, a mi juicio, el verdadero logro del proyecto. No consiste en codificar rápido. Consiste en haber cerrado el bucle entre la necesidad del despacho y la prueba de su entrega, sin salir jamás de la herramienta.

Todo comienza en la aplicación. El despacho formula sus peticiones directamente desde HORALIO. Suben a un back-office de arbitraje donde cada petición se trata: aceptada con un nivel de prioridad, planificada sobre una versión objetivo, puesta en espera, marcada como duplicada, o rechazada con un motivo explícito. El repositorio de código hace de pivote. En la aceptación, se crea un ticket automáticamente, y su cierre hace pasar la petición a «entregada» del lado del cliente. La asistencia no se limita a crear tickets: vigila el repositorio, interpreta cada petición a la luz del contexto propio del despacho, y luego prepara la planificación con los elementos requeridos, resultado esperado, descripción, impactos conexos, urgencia, criticidad, y hasta una recomendación de arbitraje. El arbitraje humano sigue siendo soberano, pero recibe un expediente ya instruido.

El despacho ve en tiempo real lo que está en curso, lo que está planificado, lo que se descarta, y por qué. La trazabilidad no es un artefacto interno reservado al equipo: es una información devuelta al cliente, con sus justificaciones. Resultado: una petición de la mañana puede ser arbitrada, desarrollada, probada y publicada en la misma jornada. La velocidad ya no está frenada por el ciclo de desarrollo. Está encuadrada por el último salvavidas que nos negamos a sacrificar, la validación humana.

La clave de bóveda: juegos de pruebas contextualizados. La asistencia produce los juegos de datos de aceptación que reflejan los casos reales del despacho, expedientes reales, roles reales, casos límite de negocio, así como las pruebas que blindan el núcleo sensible. Sin esta generación contextualizada, las pruebas de aceptación se convertirían en el cuello de botella. Con ella, probar deja de ser un freno y se convierte en el cimiento de confianza que autoriza la velocidad.

El flujo, en sus grandes líneas. Una anomalía o una necesidad detectada en el control de calidad interno se convierte en un ticket trazado. La asistencia lo instruye a la luz del contexto del despacho, alimenta una cartera de encargos priorizada y propone una secuenciación. Un plan de entrega se despliega en preproducción, acompañado de soportes de pruebas de aceptación que abarcan únicamente los desarrollos afectados, que el despacho valida o corrige sobre su propio perímetro. La integración pasa bajo doble control automatizado, y luego la puesta en producción la hace un humano, soberano, no delegado. Siguen una página de entrega legible para el cliente y una vigilancia de los registros.

Una decena de puntos de control jalonan esta cadena, cada uno afinado mediante ensayos sucesivos. El detalle de ese ajuste, es decir lo que se automatiza, lo que nunca debe automatizarse, y dónde colocar exactamente las verificaciones, constituye lo esencial del saber hacer. No se traslada de una organización a otra sin ser discutido. El aseguramiento de la calidad, puesto habitualmente el más costoso y el más descuidado de un proyecto de software, se vuelve aquí industrializado, contextualizado y continuo, sin retirar jamás al humano la decisión que compromete la producción.

Una palabra sobre las herramientas. Se ha producido un salto importante desde principios de año, tanto en la capacidad de análisis contextual como en la orquestación. Otro giro útil: la posibilidad de delegar ciertas tareas en modelos más económicos, con entregables de una calidad asombrosa. Se reparte la potencia allí donde es necesaria, y la frugalidad allí donde basta. En cuanto al coste de estas herramientas, a menudo imaginado desmesurado, se limitó a una suscripción comercial. En proporción a lo que se produjo, no es significativo. En el maquetado, un puesto entero desapareció del presupuesto, el de las herramientas gráficas: el prototipado asistido produjo maquetas cercanas en un 90 % a la versión final.

7. La barrera de calidad, no negociable

Ningún envío hacia la rama principal sin tres luces verdes: verificación de los tipos con cero errores, batería de pruebas con 163 sobre 163 pasadas, y construcción del paquete con éxito. La lógica sensible (cálculos de presupuesto, cascada de tarifas, umbrales de alerta) se extrae en funciones puras y se prueba. El resto puede moverse, ese núcleo no.

Este punto es contraintuitivo y merece subrayarse: es precisamente porque el código se produce rápido que hace falta una barrera más estricta, no más flexible. La barrera es lo que autoriza la velocidad. Sin ella, la velocidad no es más que una deuda contraída en descubierto.

8. Seguridad

El principio rector: lo que está prohibido en la pantalla debe estar prohibido del lado del servidor, y verificado como tal. En concreto, cuatro familias de medidas se aplicaron y verificaron antes de la puesta en producción: un aislamiento estricto de los datos entre despachos, sostenido por el modelo de datos y no por la interfaz; una gestión de los tokens y de los accesos temporales apoyada en mecanismos estándar, con expiración y revocación; salvavidas de entorno que impiden que la preproducción alcance destinatarios reales; y una cadena de copias de seguridad cifradas en región europea, probada de extremo a extremo, con rotación de los accesos tras la publicación.

Las propias auditorías se instrumentaron. Se pasaron agentes de auditoría ofensiva de código abierto sobre la aplicación para sondear los puntos de entrada antes de la puesta en producción. La asistencia no solo escribió el código, también sirvió para atacarlo y así endurecerlo. Varias operaciones de infraestructura sensibles se devolvieron voluntariamente al humano. Una asistencia automatizada no debe poseer las llaves de la producción sin validación.

El detalle de los mecanismos defensivos, nomenclatura de los campos de aislamiento, algoritmos exactos, plazos de validez, comportamiento de los informes compartidos, no se publica a propósito. Publicar la arquitectura defensiva de una aplicación en producción que aloja los datos de los clientes de un despacho de auditoría equivaldría a publicar su mapa.

9. Explotación y soberanía

Es aquí donde se juega la promesa hecha al despacho. Una aplicación entregada no es nada si permanece cautiva de una plataforma que no se controla. Dos piezas hacen a HORALIO realmente poseíble. La contenerización: la aplicación, sus dependencias y su entorno quedan fijados en una imagen reproducible de forma idéntica, independiente de la máquina, desplazable de un servidor a otro. Y una plataforma de despliegue autoalojada, instalada en el servidor del despacho, alternativa soberana a las plataformas comerciales. En cada envío de código, encadena migraciones y construcción, y luego un despliegue progresivo sin corte. Todo el confort del despliegue moderno, sin confiar ni el código ni los datos a un tercero.

Las trampas que no se inventan son las que cuestan horas, y ninguna es generable. Nunca concluir «desplegado» a partir de la apariencia: el único marcador fiable es la huella de la versión expuesta por la propia aplicación. Y un despliegue progresivo hace coexistir dos versiones durante aproximadamente un minuto, con la huella alternando entre ambas; un script de espera ingenuo concluye el éxito a la primera respuesta favorable, cuando el cambio no ha terminado. Otra decena de trampas del mismo orden jalonaron la puesta en producción, desde el indicador «éxito» del orquestador que no dice nada del estado real, hasta los fallos de autenticación difíciles de diagnosticar. Cada una costó tiempo una vez, y una sola.

Y la puesta en producción no es el final. Copias de seguridad cifradas hacia un almacenamiento de objetos europeo, probadas de extremo a extremo. Vigilancia de disponibilidad alojada fuera del servidor vigilado, porque un servidor no puede señalar su propia avería. Notificaciones de incidente. Procedimiento escrito de recuperación. El despacho sostiene cada eslabón de la cadena, del contenedor a la copia de seguridad, sin dependencia de un gran proveedor de nube.

Este oficio tiene un nombre: el ingeniero desplegado en el cliente

Todo lo anterior describe una manera de trabajar. No es invención mía: es un modelo establecido, con nombre, y hoy masivamente adoptado por el sector. El Forward Deployed Engineer, o FDE, que se puede traducir como ingeniero desplegado en el cliente.

El rol fue inventado y sistematizado por Palantir, cuyos primeros clientes eran agencias gubernamentales y grandes instituciones, es decir entornos donde la infraestructura es compleja, el cumplimiento normativo exigente, y donde ningún software comercial podía servir tal cual. En lugar de entregar una licencia y dejar que el cliente se las arreglara, la empresa desplegaba a sus ingenieros dentro, durante meses, para construir los casos de uso con los equipos. El modelo fue considerado durante mucho tiempo demasiado costoso y demasiado extraño para ser copiado. Ya no lo es. OpenAI montó su equipo en 2024, Anthropic desarrolló el suyo, a los que se sumaron Databricks, Scale AI, Google DeepMind y otros. Las ofertas de empleo para este puesto progresaron más de un 800 % entre enero y septiembre de 2025. En la primavera de 2026, Anthropic y OpenAI lanzaron cada uno una empresa conjunta de despliegue en empresas valorada en miles de millones, enteramente construida en torno a este rol.

El rasgo distintivo es una responsabilidad de extremo a extremo: quien cartografía el problema el primer día es quien responde cuando la producción se rompe seis meses después. Eso excluye el traspaso de relevo a un equipo de soporte que no ha concebido nada, y excluye el rol de integrador que parametriza el producto de otro. Se construye lo que falta, y se responde de ello. Los dieciséis días no son la demostración, son su consecuencia: el modelo de datos hablaba ya la lengua del despacho antes de la primera línea de código, y la persona que zanjó la reelaboración del control de acceso era la misma que respondería de la producción después.

10. Economía del método

Las restricciones económicas impusieron el método, y no al revés. Un precio deliberadamente bajo prohíbe la infraestructura costosa y el desarrollo interminable. El margen solo existe en la frugalidad. De ahí cuatro reglas que tienen todas una traducción financiera directa: un único despliegue a la vez, lo que evita las construcciones inútiles; unas pruebas de aceptación llevadas sobre la preproducción desplegada, restricción transformada en ventaja; una memoria persistente entre sesiones de asistencia, que ahorra la casi totalidad del contexto recargado en cada reanudación; y una barrera de calidad pasada en local, lo que equivale a pagar la verificación una vez en lugar de tres veces en construcciones fallidas. La velocidad de la asistencia solo reduce los costes si el método se racionaliza. Sin eso, simplemente los desplaza hacia la factura de infraestructura.

11. El equivalente en equipo humano

Es la estimación más discutida, así que tratemos la objeción antes de que se formule. Estimar una carga humana a partir de un número de líneas es un método cuestionado, y lo es todavía más aquí: el código asistido es de media más verboso que el código escrito a mano. Contar las líneas sobrestima por tanto mecánicamente el esfuerzo equivalente. El orden de magnitud no reposa sobre el volumen, sino sobre la lista de entregables, cada uno de ellos verificable:

una aplicación multiinquilino con control de acceso y aislamiento de los datos;
un back-office de administración entregado simultáneamente (aprovisionamiento, arbitraje de las peticiones, supervisión);
una documentación funcional y una documentación técnica;
un cuaderno de pruebas específico del cliente;
una función de pruebas de aceptación contextualizada, sección por sección y rol por rol, integrada en el producto;
un registro de las entregas y su gestión;
una cadena de explotación completa, copias de seguridad, vigilancia, procedimiento de recuperación.

Son precisamente esos añadidos, nunca glamurosos, los que los proyectos reales sacrifican casi siempre. Cifrar este perímetro a la antigua conduce, sea cual sea el método de estimación adoptado, a un equipo pluridisciplinar de cinco a seis personas movilizado varios meses, es decir del orden de treinta hombres-mes. Los ocho roles orquestados (el término de agente recubre aquí roles distintos, sostenidos por una misma persona que se apoya en una asistencia especializada en cada etapa): encuadre y análisis funcional, arquitectura, diseño y maquetado, desarrollo, revisión de código y seguridad, pruebas de aceptación, entrega y explotación, documentación.

Los órdenes de magnitud, mercado Francia, a ajustar según el perímetro. En interno, una treintena de hombres-mes en masa salarial cargada conduce a unos 180 a 230 k€. En prestación, con tarifa diaria mixta, margen y coordinación, más bien 350 a 500 k€. HORALIO fue construido por un piloto experimentado en tres semanas, infraestructura compartida, suscripción de asistencia, por una fracción de esos importes. La diferencia no es un descuento comercial, es un cambio de naturaleza. El importe exacto no figura aquí deliberadamente: depende demasiado del perímetro, y una cifra aislada siempre se vuelve contra quien la publica.

12. Del servicio alquilado al software poseído

Se ha operado un vuelco de modelo. Ya no un servicio compartido, sino un servidor dedicado al despacho, donde los datos se alojan y se pilotan con pleno control. La contenerización y el despliegue autoalojado son exactamente lo que hace este paso tangible en lugar de teórico. La asistencia jugó aquí tres roles simultáneos: una transferencia de competencia, ya que la lógica de la herramienta es explícita y dominada; un acelerador, dieciséis días en lugar de años de iteraciones; y un creador de valor, al dejar la aplicación de ser una carga de alquiler para convertirse en un activo poseído.

La fórmula, sin ambigüedad. La propiedad es el principio, no una opción. El despacho hace desplegar la aplicación en su propio servidor y se convierte en su propietario, código y datos incluidos. Una instancia que nosotros alojamos sigue siendo posible para arrancar sin movilizar infraestructura, pero está pensada desde el origen como reversible: la salida está prevista, documentada, y no depende de ninguna autorización por nuestra parte. Un software que no se puede llevar consigo no es un software que se posee, y una cláusula contractual no reemplaza a un artefacto desplazable.

13. Lo que viene

La evolución está trazada: embarcar en el servidor dedicado un modelo aligerado, alojado localmente, para hacer nacer un asistente que trabaje lo más cerca posible de los datos del despacho. Modelo dominado, alojamiento soberano, datos que no salen. La inteligencia integrada en el activo, en lugar de alquilada en el exterior. Otras piezas seguirán probablemente, una planificación de los recursos, una nómina simplificada apoyada en el dispositivo simplificado del organismo de recaudación social. Cada una se injerta sobre el cimiento existente.

14. La reserva honesta: ¿y si el modelo económico de la asistencia cambiara?

Todo lo anterior reposa sobre una condición que no controlo: la estabilidad del modelo de facturación de los proveedores de modelos. La economía de este proyecto depende de una suscripción de tarifa fija, hoy ampliamente subvencionada por las rondas de financiación del sector. Si la facturación basculara hacia una tarificación por uso ajustada al coste real de producción, la ecuación cambiaría para todo el mundo, incluido yo.

No es una hipótesis de manual, está ocurriendo. El caso de Anthropic con su modelo más potente, Fable 5, es instructivo. Lanzado a principios de junio de 2026, fue primero suspendido unos días después por una razón sin relación con los precios, una restricción estadounidense a la exportación ligada a inquietudes sobre usos en ciberseguridad, antes de su reapertura el 1 de julio. Luego, en el plano tarifario, el arbitraje cayó el 20 de julio: el modelo sigue incluido sin fecha de fin en las fórmulas de gama alta, hasta la mitad de los límites semanales, mientras que las fórmulas de entrada de gama basculan hacia créditos de uso de pago. Dicho de otro modo, el vuelco hacia el uso sí tuvo lugar, no fue anulado, y golpea primero a las cuentas pequeñas.

Para un proyecto como este, la consecuencia es simple de enunciar: la frugalidad metodológica descrita más arriba no es una coquetería de ingeniero. Es una cobertura.

15. Dónde está la plusvalía

La inteligencia artificial ha multiplicado realmente la velocidad. Pero seamos lúcidos sobre el lugar donde se encuentra el valor. Muchos se equivocan de combate. Resumir correos y producir planes de acción es simpático, limitado y costoso. Muy grandes empresas están hoy dando marcha atrás ante la escalada de los costes. Distribuir asistentes conversacionales y obligar a cada uno a hacer releer sus mensajes es la ilusión de la transformación. La transformación real exige un trabajo quirúrgico: identificar con precisión dónde se encuentran los puntos de mejora organizativa y de multiplicación de los márgenes. Esa altura de miras la máquina no la aporta. La aportan los profesionales del oficio, todavía por un tiempo.

Lo que hizo sostenerse a HORALIO no es la generación de código. Es el método, y el criterio de saber cuándo no codificar rápido.

En concreto: una barrera de calidad no negociable, pruebas sobre el núcleo sensible, reglas protegidas del lado del servidor, un único despliegue a la vez, una verificación por la huella y no por la apariencia, unas pruebas de aceptación que pesan tanto como el desarrollo, y la decisión de puesta en producción dejada a un humano.

HORALIO está en producción, en la dirección horalio.net. Unas 39.000 líneas, dieciséis días, ocho roles orquestados, una auditoría de seguridad superada antes de la publicación. Y, para un despacho, el comienzo de la propiedad plena y entera de su herramienta.

La inteligencia artificial no reemplaza la pericia, la experiencia, la memoria, la intuición. Las amplifica de forma vertiginosa. Pero multiplica igual de rápido los errores, los callejones sin salida y los bucles de quien no las tiene.

Preguntas frecuentes

¿Cómo pudo un software de negocio llegar a producción en dieciséis días?

Lo raro no fue la generación de código, sino la disciplina que la dirigió: un modelo de datos que ya hablaba el idioma del despacho, una barrera de calidad estricta y una fase de pruebas contextualizada tan costosa como el propio desarrollo.

¿Qué posee realmente el despacho?

Más allá del código y los datos, el activo duradero es el modelo explícito y formalizado de su propio trabajo: su manera de concebir una misión, un tiempo facturable, una regla de confidencialidad. El código que lo expresa hoy podría regenerarse en unos días; lo contrario no es cierto.

¿Por qué una regla de negocio debe protegerse en el servidor?

Porque una prohibición mostrada solo en pantalla se sortea con una llamada directa. Una regla de negocio no protegida en el servidor no existe. El aislamiento de datos entre despachos y el control de accesos los sostiene el modelo, no la interfaz.

Retorno de experiencia técnico. HORALIO, un software de negocio poseído, en producción en horalio.net.

← Todos los artículos Contáctenos →

← News

Relato de experiência · Técnico

Um software de gestão em dezasseis dias, e as salvaguardas que o tornam defensável.

por José Vazquez

7 de agosto de 2026 · Ver HORALIO em produção →

Uma sociedade de auditoria e de contabilidade dotou-se de um software de registo de tempo, feito à medida, testado, documentado, em produção, em dezasseis dias. A aplicação está em serviço e pertence-lhe. Funciona no endereço horalio.net. O que foi raro neste projeto não foi a geração de código. Foi a disciplina que permitiu ousar colocá-lo em produção.

Eis o relato de experiência técnico, em duas partes: como se constrói, e depois o que isso muda. O que é raro não é a velocidade, é o discernimento que a dirige.

1. O que a velocidade desloca

Quando uma máquina produz código mais depressa do que um humano o relê, o risco muda de natureza. Já não está na dificuldade de escrever, está na deriva silenciosa: uma convenção que se desfaz de uma sessão para a outra, uma decisão de arquitetura esquecida e depois contradita três dias mais tarde, uma regra de negócio colocada no ecrã mas não no sítio certo, um teste vermelho contornado porque se está com pressa.

Nada disto é espetacular. É exatamente por essa razão que é perigoso. Um projeto assistido que falha não explode, apodrece.

Tudo o que se segue tem um único objetivo: tornar a deriva impossível sem que se dê por ela. É isso, e não a geração, que constitui o saber-fazer.

2. A origem e o perímetro real

Uma sociedade de auditoria e de contabilidade quer agilizar os seus processos internos e dotar-se de um software de registo de tempo «ultra simplificado». Toda a conceção assentou nesta palavra, e vale a pena deter-se nela, porque é enganadora. O ultra simples é multidimensional e caro de produzir. É um resultado, não uma característica: o que resta depois de todos os arbítrios estarem decididos. Um software rico é um software que não decidiu nada e que transferiu cada decisão para o utilizador, disfarçando-a de liberdade de configuração. É muito mais fácil de construir.

Cinco dimensões distintas, que não se reduzem umas às outras: simples de introduzir (número de gestos, valores por omissão certos, ausência de navegação), simples de aprender (promessa falsificável: ou um novo colaborador consegue sozinho, ou ela é falsa), simples de adotar (a ferramenta fala o vocabulário da casa, não há nada a traduzir), simples de ler (o responsável que consulta não tem as necessidades do colaborador que introduz, e a simplicidade da leitura não se deduz da simplicidade da introdução), simples de manter (menos opções, menos estados, menos combinações a testar).

Duas consequências de engenharia comandam todo o resto. Primeiro, a simplicidade remonta até ao modelo de dados. Não se decide na interface. Se a estrutura conceber mal o mundo do cliente, nenhum ecrã poderá ser simples: será preciso pedir ao utilizador que compense à mão aquilo que o modelo não sabe representar. Uma interface complicada é quase sempre o sintoma de um modelo que pensa torto. Depois, a geração assistida torna a simplicidade mais difícil de manter, não mais fácil. Enquanto acrescentar uma função custava caro, o orçamento arbitrava no nosso lugar. Quando o acréscimo se torna quase gratuito, esse garante desaparece: a máquina acrescentará tudo o que lhe pedirmos, imediatamente, de forma limpa, sem nunca objetar. A simplicidade deixa de ser uma restrição orçamental para se tornar uma pura questão de discernimento.

Duas outras exigências completam a encomenda: capacidades de personalização muito fortes (tipos de missões, designações, regras, dossiês), e a constituição de um ativo para a empresa. O que é personalizado não é um conjunto de opções oferecido ao utilizador, é a própria estrutura, arbitrada antes da primeira linha de código. E o verdadeiro filão não é a introdução, é o dado que ela produz: rastreabilidade interna para a gestão das missões, transparência perante o cliente sem expor custos nem margens, e fiabilização das declarações regulamentares junto da supervisão da profissão, onde a qualidade das declarações depende diretamente da fiabilidade dos tempos declarados.

Os números, para situar:

Linhas versionadas: cerca de 39 100.
Commits em dezasseis dias: 269 (o primeiro a 7 de julho, entrada em produção a 21).
Componentes de interface: 122.
Testes automatizados: 163 no momento da entrada em produção.
Papéis de assistência orquestrados: 8.
Do lado do servidor: 14 módulos de ações de servidor, 10 rotas aplicacionais, 25 módulos de lógica de negócio pura, sobre uma base relacional de 805 linhas de esquema e 23 migrações.

O perímetro, e aquilo que sempre se subestima. A interface (cerca de 23 400 linhas, 122 componentes) cobre a introdução, os painéis de bordo, os relatórios, a parametrização, um percurso de acolhimento em seis etapas e uma versão móvel unificada. É a parte que a assistência gera mais depressa, e aquela em que o «parece acabado» mais engana. O servidor sustenta o essencial: isolamento entre sociedades, controlo dos acessos, cálculos de orçamento. Invisível, mas é o verdadeiro produto. Os testes de aceitação são a parte mais subestimada, e custaram tanto como o desenvolvimento: 163 testes automatizados, passagens manuais que chegaram a cinquenta e cinco pontos de controlo de uma só vez, quatro conjuntos de dados a refletir os verdadeiros dossiês, e um teste de aceitação em navegador sistemático antes de cada entrega.

O desenvolvimento ao correr da pena, sem testes de aceitação, não é desenvolvimento rápido. É desenvolvimento amputado.

3. Enquadramento: a assistência acelera, não decide

A assistência é excelente a produzir um caderno de encargos, cenários de utilização e um modelo de dados em poucas horas. O limite chega depressa, e chega sempre no mesmo sítio: à primeira alteração que toca na estrutura.

A sociedade pede que vários colaboradores possam intervir num mesmo dossiê. Na base de dados, a afetação assentava numa relação simples, um colaborador para um dossiê. Fazê-lo bem exigia uma tabela de ligação e, na sequência, uma reformulação do controlo de acesso. Um desenvolvimento ao correr da pena teria improvisado um contorno pela noite dentro. A boa decisão foi suspender, arbitrar com o cliente, e tratar o pedido como um projeto de fundo.

A experiência é saber o que não se codifica já.

4. O modelo do mundo do cliente

Esta decisão merece que nos detenhamos nela, porque toca no verdadeiro objeto deste projeto e no único ativo dificilmente reproduzível. O termo consagrado é a ontologia. Vou empregá-lo pouco, porque afugenta e porque faz crer em teoria. Trata-se de uma coisa muito concreta: os objetos de que uma organização fala, as regras que os governam, e a ordem pela qual essas regras se aplicam. Os seus nomes, os seus verbos, a sua gramática.

Não é o esquema da base de dados. O esquema é uma implementação dele, num dado momento, numa dada tecnologia. Pode implementar-se perfeitamente um modelo falso, e é até o caso mais frequente: normalizado, indexado, restringido, e a descrever um mundo que não é o do cliente.

Um exemplo retirado deste projeto. A cascata de taxas aplicada aos tempos introduzidos segue uma ordem de especificidade estrita, do mais particular ao mais geral: uma taxa fixada para um colaborador num projeto dado sobrepõe-se a uma taxa de projeto, que se sobrepõe a uma taxa de cliente, que se sobrepõe à taxa da sociedade. Tecnicamente, é uma função de resolução de umas quantas linhas. Concetualmente, é uma afirmação sobre o mundo: esta sociedade defende que o particular prevalece sempre sobre o geral em matéria de valorização. Outra sociedade poderia decidir o contrário. Nenhum software genérico coloca alguma vez esta questão, e é por isso que tantos utilizadores corrigem os seus mapas à mão depois da extração. Esta regra é extraída para uma função pura e testada, precisamente porque não é técnica. O código pode mudar, a regra não.

O primeiro gesto de enquadramento: pedir os ficheiros paralelos. A maneira mais rápida de detetar um desacordo entre o modelo instalado e o negócio real é olhar para o que gravita à volta do software oficial. Folhas de cálculo mantidas à mão que ninguém encomendou, campos livres preenchidos com códigos transmitidos oralmente, convenções de nomenclatura que carregam uma informação estruturada que a ferramenta não sabe armazenar, uma dupla introdução que já ninguém contesta porque é anterior a toda a gente.

Estes artefactos não são indisciplina. São os fragmentos do negócio real, expulsos do sistema porque ele não os sabia acolher, e reinjetados à mão por pessoas que sabem do que falam. Cada um é uma especificação gratuita, já redigida, à espera de ser lida. É a primeira coisa que peço ao chegar, antes de qualquer discussão de necessidade: mostrem-me os vossos ficheiros paralelos. Uma hora passada sobre eles vale um dia de atelier.

Porque é que isto não se recolhe por escrito. O essencial é tácito. Pergunte a um sócio o que é uma missão: obterá uma definição clara, numa frase, imediatamente. Observe depois a sociedade a trabalhar, e encontrará várias categorias de missões com comportamento distinto, algumas das quais ele nunca pensaria mencionar por lhe parecerem óbvias. Não é imprecisão nem retenção. É a natureza do saber profissional: aquilo que se domina melhor é aquilo que menos se explicita. A técnica que funciona é contraintuitiva: propor uma formulação deliberadamente aproximada e esperar a correção. Um modelo exibido e ligeiramente falso desencadeia em trinta segundos um «não, não é bem assim, na verdade é mais...» que três reuniões de recolha não teriam produzido. É a justificação técnica, e não comercial, do trabalho no local.

Um critério operacional, transponível já amanhã. Chega um pedido. Antes de o estimar, coloque uma única questão: até onde se propaga? Se fica num ecrã, é uma funcionalidade. Estima-se, planeia-se, entrega-se. Se toca ao mesmo tempo no controlo de acesso, nos relatórios e no histórico, não é uma funcionalidade. É o modelo que estava falso, e passa a ser um projeto de fundo. O episódio dos dossiês partilhados é a sua ilustração exata: «vários colaboradores num dossiê» apresentava-se como um campo a duplicar, duas horas de trabalho. Na realidade o sistema tinha como adquirido que um dossiê pertence a um colaborador, e as regras de confidencialidade derivavam desse pertencimento.

A propagação é a assinatura. E é precisamente aí que um desenvolvimento assistido não dirigido produz o seu pior resultado. A máquina sabe perfeitamente criar uma tabela de ligação, migrar os dados e adaptar os ecrãs. O que ela não sabe é que, ao fazê-lo, acabou de invalidar silenciosamente um modelo de segurança. O código compilará, os testes existentes passarão, e a falha ficará à espera dos testes de aceitação. Ou pior, da produção.

O que é realmente possuído. Dizemos que a sociedade possui o seu software. É exato quanto ao código e aos dados. Mas o valor duradouro não está aí. O código tem uma esperança de vida de alguns anos, e a geração assistida tornará a sua substituição quase indolor. Em contrapartida, a maneira como uma sociedade de auditoria concebe uma missão, um tempo declarável, uma regra de confidencialidade perante um confrade, evolui à escala de uma década. O que a sociedade possui realmente é o modelo explícito e formalizado do seu próprio trabalho. O código que o exprime hoje poderia ser regenerado em poucos dias a partir desse modelo. O inverso não é verdade. A pilha técnica deste projeto copia-se numa tarde. A compreensão da forma como um revisor oficial de contas justifica o seu tempo perante a sua supervisão não se copia, porque não está escrita em lado nenhum.

5. Arquitetura e regras de negócio, onde a geração se torna perigosa

O coração do produto são regras de confidencialidade: quem vê o quê, e sobretudo quem não vê o quê. A armadilha do código gerado à pressa é sempre a mesma: a regra é colocada onde se vê, ou seja, na interface, e em mais lado nenhum. Um controlo constatado nos testes de aceitação ilustrava-o na perfeição: uma proibição de introdução corretamente exibida no ecrã, mas ausente do lado do servidor, logo contornável por uma chamada direta.

Uma regra de negócio não guardada do lado do servidor não existe.

O princípio parece elementar, e no entanto nem sempre é respeitado por softwares do mercado instalados há muito tempo, onde um controlo exibido no ecrã se contorna por uma chamada direta. O que se julga proibido fica por vezes escancarado do lado dos dados. Outra dívida clássica, e mais insidiosa: a mesma regra duplicada tal e qual em sete ficheiros. Gerá-la sete vezes custa alguns segundos. Identificá-la, centralizá-la e garantir que não se voltará a duplicar é matéria de saber-fazer, não de geração.

6. O ciclo cliente, do pedido à prova de entrega

É aqui que se encontra, a meu ver, o verdadeiro feito do projeto. Não consiste em codificar depressa. Consiste em ter fechado o ciclo entre a necessidade da sociedade e a prova da sua entrega, sem nunca sair da ferramenta.

Tudo começa na aplicação. A sociedade formula os seus pedidos diretamente a partir do HORALIO. Eles sobem para um back-office de arbitragem onde cada pedido é tratado: aceite com um nível de prioridade, planeado para uma versão-alvo, posto em espera, marcado como duplicado, ou recusado com um motivo explícito. O repositório de código desempenha o papel de eixo. Na aceitação, é criado automaticamente um ticket, e o seu fecho faz o pedido passar a «entregue» do lado do cliente. A assistência não se limita a criar tickets: vigia o repositório, interpreta cada pedido à luz do contexto próprio da sociedade, e depois prepara o planeamento com os elementos requeridos, o esperado, a descrição, os impactos conexos, a urgência, a criticidade, e até uma recomendação de arbitragem. A arbitragem humana continua soberana, mas recebe um dossiê já instruído.

A sociedade vê em tempo real o que está em curso, o que está planeado, o que foi afastado, e porquê. A rastreabilidade não é um artefacto interno reservado à equipa: é uma informação devolvida ao cliente, com as suas justificações. Resultado: um pedido da manhã pode ser arbitrado, desenvolvido, testado e posto em linha na sequência. A velocidade já não é travada pelo ciclo de desenvolvimento. É enquadrada pelo último garante que nos recusamos a sacrificar, a validação humana.

A pedra angular: conjuntos de testes contextualizados. A assistência produz os conjuntos de dados de teste de aceitação que refletem os verdadeiros casos da sociedade, dossiês reais, papéis reais, casos-limite de negócio, bem como os testes que blindam o núcleo sensível. Sem essa geração contextualizada, os testes de aceitação tornar-se-iam o estrangulamento. Com ela, testar deixa de ser um travão e torna-se o alicerce de confiança que autoriza a velocidade.

O fluxo, nas suas grandes linhas. Uma anomalia ou uma necessidade detetada nos testes de aceitação internos torna-se um ticket rastreado. A assistência instrui-o à luz do contexto da sociedade, alimenta uma carteira de encomendas priorizada e propõe um sequenciamento. Um plano de entrega é implantado em pré-produção, acompanhado de suportes de teste de aceitação incidindo unicamente sobre os desenvolvimentos em causa, que a sociedade valida ou emenda no seu próprio perímetro. A integração passa por duplo controlo automatizado, e depois a entrada em produção é feita por um humano, soberano, não delegado. Seguem-se uma página de entrega legível para o cliente e uma vigilância dos registos.

Uma dezena de pontos de controlo balizam esta cadeia, cada um afinado por ensaios sucessivos. O detalhe dessa afinação, ou seja, o que é automatizado, o que nunca o deve ser, e onde colocar exatamente as verificações, constitui o essencial do saber-fazer. Não se transpõe de uma organização para outra sem ser discutido. A garantia de qualidade, posto habitualmente mais caro e mais negligenciado de um projeto de software, torna-se aqui industrializada, contextualizada e contínua, sem nunca retirar ao humano a decisão que compromete a produção.

Uma palavra sobre a ferramentaria. Deu-se um salto importante desde o início do ano, tanto na capacidade de análise contextual como na orquestração. Outra viragem útil: a possibilidade de delegar certas tarefas a modelos mais económicos, com entregáveis de uma qualidade surpreendente. Distribui-se a potência onde ela é necessária, e a frugalidade onde ela basta. Quanto ao custo desta ferramentaria, muitas vezes imaginado desmedido, limitou-se a uma subscrição comum. Face ao que foi produzido, não é significativo. Na maquetagem, um posto inteiro desapareceu do orçamento, o das ferramentas gráficas: a prototipagem assistida produziu maquetas próximas a cerca de 90 % da versão final.

7. A barreira de qualidade, não negociável

Nenhum envio para o ramo principal sem três luzes verdes: verificação de tipos com zero erros, conjunto de testes com 163 em 163 aprovados, e construção do pacote com sucesso. A lógica sensível (cálculos de orçamento, cascata de taxas, limiares de alerta) é extraída para funções puras e testada. O resto pode mexer-se, este núcleo não.

Este ponto é contraintuitivo e merece ser sublinhado: é precisamente porque o código é produzido depressa que é preciso uma barreira mais estrita, não mais frouxa. A barreira é o que autoriza a velocidade. Sem ela, a velocidade não passa de uma dívida contraída a descoberto.

8. Segurança

O princípio orientador: o que é proibido no ecrã deve ser proibido do lado do servidor, e verificado como tal. Concretamente, quatro famílias de medidas foram aplicadas e verificadas antes da entrada em produção: um isolamento estrito dos dados entre sociedades, sustentado pelo modelo de dados e não pela interface; uma gestão de tokens e de acessos temporários assente em mecanismos padrão, com expiração e revogação; garantes de ambiente que impedem a pré-produção de atingir destinatários reais; e uma cadeia de cópias de segurança cifradas em região europeia, testada de ponta a ponta, com rotação dos acessos após a colocação em linha.

As próprias auditorias foram apetrechadas. Agentes de auditoria ofensiva de código aberto foram passados sobre a aplicação para sondar os pontos de entrada antes da entrada em produção. A assistência não só escreveu o código, como também serviu para o atacar a fim de o endurecer. Várias operações de infraestrutura sensíveis foram voluntariamente devolvidas ao humano. Uma assistência automatizada não deve deter as chaves da produção sem validação.

O detalhe dos mecanismos defensivos, nomenclatura dos campos de isolamento, algoritmos exatos, durações de validade, comportamento dos relatórios partilhados, não é publicado de propósito. Publicar a arquitetura defensiva de uma aplicação em produção que aloja os dados de clientes de uma sociedade de auditoria equivaleria a publicar o seu mapa.

9. Exploração e soberania

É aqui que se joga a promessa feita à sociedade. Uma aplicação entregue não é nada se ficar cativa de uma plataforma que não se domina. Duas peças tornam o HORALIO realmente possuível. A conteinerização: a aplicação, as suas dependências e o seu ambiente ficam fixados numa imagem reproduzível tal e qual, independente da máquina, deslocável de um servidor para outro. E uma plataforma de implantação auto-hospedada, instalada no servidor da sociedade, alternativa soberana às plataformas comerciais. A cada envio de código, encadeia migrações e construção, e depois uma implantação progressiva sem interrupção. Todo o conforto da implantação moderna, sem confiar o código nem os dados a um terceiro.

As armadilhas que não se inventam são as que custam horas, e nenhuma é gerável. Nunca concluir «implantado» a partir da aparência: o único marcador fiável é a impressão da versão exposta pela própria aplicação. E uma implantação progressiva faz coexistir duas versões durante cerca de um minuto, com a impressão a alternar entre as duas; um script de espera ingénuo conclui pelo sucesso à primeira resposta favorável, quando a transição ainda não terminou. Uma dezena de outras armadilhas do mesmo género balizaram a entrada em produção, do sinal «sucesso» do orquestrador que nada diz do estado real, às falhas de autenticação difíceis de diagnosticar. Cada uma custou tempo uma vez, e uma só.

E a entrada em produção não é o fim. Cópias de segurança cifradas para um armazenamento de objetos europeu, testadas de ponta a ponta. Vigilância de disponibilidade hospedada fora do servidor vigiado, porque um servidor não pode assinalar a sua própria avaria. Notificações de incidente. Procedimento escrito de recuperação. A sociedade detém cada elo da cadeia, do contentor à cópia de segurança, sem dependência de um grande fornecedor de nuvem.

Este ofício tem um nome: o Forward Deployed Engineer

Tudo o que precede descreve uma maneira de trabalhar. Não é da minha invenção: é um modelo estabelecido, nomeado, e hoje massivamente adotado pelo setor. O Forward Deployed Engineer, ou FDE, que se pode traduzir em português por engenheiro destacado no cliente.

O papel foi inventado e sistematizado pela Palantir, cujos primeiros clientes eram agências governamentais e grandes instituições, ou seja, ambientes onde a infraestrutura é complexa, a conformidade exigente, e onde nenhum software comercial podia servir tal e qual. Em vez de entregar uma licença e deixar o cliente desenrascar-se, a empresa destacava os seus engenheiros para dentro, durante meses, a fim de construir os casos de uso com as equipas. O modelo foi durante muito tempo considerado demasiado caro e demasiado estranho para ser copiado. Já não o é. A OpenAI montou a sua equipa em 2024, a Anthropic desenvolveu a sua, a que se juntaram a Databricks, a Scale AI, a Google DeepMind e outras. As ofertas de emprego para este posto progrediram mais de 800 % entre janeiro e setembro de 2025. Na primavera de 2026, a Anthropic e a OpenAI lançaram cada uma uma joint venture de implantação em empresa cifrada em milhares de milhões, inteiramente construída à volta deste papel.

O traço distintivo é uma responsabilidade de ponta a ponta: quem cartografa o problema no primeiro dia é quem responde quando a produção quebra seis meses mais tarde. Isto exclui a passagem de testemunho para uma equipa de suporte que nada concebeu, e exclui o papel de integrador que parametriza o produto de outrem. Constrói-se o que falta, e responde-se por isso. Os dezasseis dias não são a demonstração, são a sua consequência: o modelo de dados já falava a língua da sociedade antes da primeira linha de código, e a pessoa que decidiu sobre a reformulação do controlo de acesso era a mesma que responderia depois pela produção.

10. Economia do método

As restrições económicas impuseram o método, e não o inverso. Um preço voluntariamente baixo proíbe a infraestrutura cara e o desenvolvimento sem fim. A margem só existe na frugalidade. Daí quatro regras que têm todas uma tradução financeira direta: uma única implantação de cada vez, o que evita construções inúteis; um teste de aceitação conduzido sobre a pré-produção implantada, restrição transformada em vantagem; uma memória persistente entre sessões de assistência, que poupa a quase totalidade do contexto recarregado a cada retoma; e uma barreira de qualidade passada em local, o que equivale a pagar a verificação uma vez em vez de três vezes em construções falhadas. A velocidade da assistência só reduz os custos se o método for racionalizado. Sem isso, ela apenas os desloca para a fatura de infraestrutura.

11. O equivalente em equipa humana

É a estimativa mais discutida, por isso tratemos a objeção antes que seja formulada. Estimar uma carga humana a partir de um número de linhas é um método contestado, e é-o ainda mais aqui: o código assistido é em média mais verboso do que o código escrito à mão. Contar as linhas sobrestima portanto mecanicamente o esforço equivalente. A ordem de grandeza não assenta no volume, mas na lista dos entregáveis, cada um deles verificável:

uma aplicação multi-inquilino com controlo de acesso e isolamento dos dados;
um back-office de administração entregue em simultâneo (aprovisionamento, arbitragem dos pedidos, supervisão);
uma documentação funcional e uma documentação técnica;
um caderno de testes específico do cliente;
uma função de teste de aceitação contextualizada, secção a secção e papel a papel, integrada no produto;
um registo das entregas e a sua gestão;
uma cadeia de exploração completa, cópias de segurança, vigilância, procedimento de recuperação.

São precisamente estes acessórios, nunca glamorosos, que os projetos reais quase sempre sacrificam. Orçamentar este perímetro à antiga conduz, seja qual for o método de estimativa adotado, a uma equipa pluridisciplinar de cinco a seis pessoas mobilizada vários meses, ou seja da ordem dos trinta homens-mês. Os oito papéis orquestrados (o termo agente recobre aqui papéis distintos, desempenhados por uma mesma pessoa que se apoia numa assistência especializada em cada etapa): enquadramento e análise funcional, arquitetura, design e maquetagem, desenvolvimento, revisão de código e segurança, testes de aceitação, entrega e exploração, documentação.

As ordens de grandeza, mercado França, a ajustar conforme o perímetro. Internamente, uma trintena de homens-mês em massa salarial carregada conduz a cerca de 180 a 230 k€. Em prestação, com tarifa diária mista, margem e coordenação, antes 350 a 500 k€. O HORALIO foi construído por um piloto experiente em três semanas, infraestrutura partilhada, subscrição de assistência, por uma fração destes montantes. A diferença não é um desconto comercial, é uma mudança de natureza. O montante exato não figura aqui de propósito: depende demasiado do perímetro, e um número isolado vira-se sempre contra quem o publica.

12. Do serviço alugado ao software possuído

Operou-se uma viragem de modelo. Já não um serviço partilhado, mas um servidor dedicado à sociedade, onde os dados são alojados e geridos em pleno domínio. A conteinerização e a implantação auto-hospedada são exatamente o que torna esta passagem tangível em vez de teórica. A assistência desempenhou aqui três papéis em simultâneo: uma transferência de competência, uma vez que a lógica da ferramenta é explícita e dominada; um acelerador, dezasseis dias em vez de anos de iterações; e um criador de valor, deixando a aplicação de ser um encargo de aluguer para se tornar um ativo detido.

A fórmula, sem ambiguidade. A propriedade é o princípio, não uma opção. A sociedade manda implantar a aplicação no seu próprio servidor e torna-se sua proprietária, código e dados incluídos. Uma instância que nós alojamos continua possível para arrancar sem mobilizar infraestrutura, mas é pensada desde a origem como reversível: a saída está prevista, documentada, e não depende de qualquer autorização da nossa parte. Um software que não se pode levar não é um software que se possui, e uma cláusula contratual não substitui um artefacto deslocável.

13. O que se segue

A evolução está traçada: embarcar no servidor dedicado um modelo aligeirado, alojado localmente, para fazer nascer um assistente que trabalha o mais perto possível dos dados da sociedade. Modelo dominado, alojamento soberano, dados que não saem. A inteligência integrada no ativo, em vez de alugada no exterior. Outras peças seguir-se-ão provavelmente, um planeamento dos recursos, um processamento salarial simplificado apoiado no dispositivo simplificado do organismo de cobrança da segurança social. Cada uma se enxerta no alicerce existente.

14. A reserva honesta: e se o modelo económico da assistência mudasse?

Tudo o que precede assenta numa condição que não domino: a estabilidade do modelo de faturação dos fornecedores de modelos. A economia deste projeto deve-se a uma subscrição fixa, hoje largamente subsidiada pelas rondas de financiamento do setor. Se a faturação passasse para uma tarifação ao uso calibrada pelo custo real de produção, a equação mudaria para toda a gente, inclusive para mim.

Não é uma hipótese de manual, está a acontecer. O caso da Anthropic com o seu modelo mais poderoso, o Fable 5, é instrutivo. Lançado no início de junho de 2026, foi primeiro suspenso uns dias mais tarde por uma razão sem relação com os preços, uma restrição norte-americana à exportação ligada a inquietações sobre usos em cibersegurança, antes da reabertura a 1 de julho. Depois, no plano tarifário, o arbítrio caiu a 20 de julho: o modelo mantém-se incluído sem data de fim nas fórmulas topo de gama, até metade dos limites semanais, ao passo que as fórmulas de entrada de gama passam para créditos de uso pagos. Por outras palavras, a passagem ao uso teve mesmo lugar, não foi anulada, e atinge primeiro as pequenas contas.

Para um projeto como este, a consequência é simples de enunciar: a frugalidade metodológica descrita acima não é um capricho de engenheiro. É uma cobertura.

15. Onde está a mais-valia

A inteligência artificial multiplicou realmente a velocidade. Mas sejamos lúcidos sobre o sítio onde está o valor. Muitos enganam-se de combate. Resumir e-mails e produzir planos de ação é simpático, limitado e caro. Grandíssimas empresas dão hoje marcha atrás perante a disparada dos custos. Distribuir assistentes conversacionais e obrigar cada um a mandar reler as suas mensagens é a ilusão da transformação. A transformação real exige um trabalho cirúrgico: identificar com precisão onde estão os pontos de melhoria organizacional e de multiplicação das margens. Essa altura de vista, a máquina não a traz. São os praticantes que a trazem, ainda por algum tempo.

O que fez o HORALIO aguentar-se não foi a geração de código. Foi o método, e o discernimento de saber quando não codificar depressa.

Concretamente: uma barreira de qualidade não negociável, testes sobre o núcleo sensível, regras guardadas do lado do servidor, uma única implantação de cada vez, uma verificação pela impressão e não pela aparência, um teste de aceitação que pesa tanto como o desenvolvimento, e a decisão de entrada em produção deixada a um humano.

O HORALIO está em produção, no endereço horalio.net. Cerca de 39 000 linhas, dezasseis dias, oito papéis orquestrados, uma auditoria de segurança passada antes da colocação em linha. E, para uma sociedade, o início da propriedade plena e inteira da sua ferramenta.

A inteligência artificial não substitui a competência, a experiência, a memória, a intuição. Amplifica-as de forma vertiginosa. Mas multiplica igualmente depressa os erros, os becos sem saída e os ciclos de quem não os tem.

Perguntas frequentes

Como pôde um software de negócio chegar a produção em dezasseis dias?

O que foi raro não foi a geração de código, mas a disciplina que a dirigiu: um modelo de dados que já falava a língua da sociedade, uma barreira de qualidade estrita e uma fase de testes contextualizada tão dispendiosa como o próprio desenvolvimento.

O que é que a sociedade possui realmente?

Para além do código e dos dados, o ativo duradouro é o modelo explícito e formalizado do seu próprio trabalho: a sua forma de conceber uma missão, um tempo faturável, uma regra de confidencialidade. O código que o exprime hoje poderia ser regenerado em poucos dias; o inverso não é verdade.

Porque é que uma regra de negócio deve ser protegida no servidor?

Porque uma proibição mostrada apenas no ecrã contorna-se com uma chamada direta. Uma regra de negócio não protegida no servidor não existe. O isolamento de dados entre sociedades e o controlo de acessos são suportados pelo modelo, não pela interface.

Relato de experiência técnico. HORALIO, um software de negócio possuído, em produção em horalio.net.

← Todos os artigos Contacte-nos →