Timorga lance TimAtlas : garder la maîtrise de l'outil le plus puissant que nous ayons eu

Ce que nous annonçons

TimAtlas est un référentiel, et la méthode qui va avec, pour maîtriser et contrôler le travail de l'IA sur un système d'information.

Il décrit votre système dans votre vocabulaire — objets d'architecture, processus métier, fonctionnalités, modèle de données jusqu'au champ, règles de gestion, dépendances. Il dit ce qui doit être produit avant que l'IA ne produise, et il prouve ce qui l'a été. À côté du référentiel, il construit la route à parcourir : ce qu'il faut faire, dans quel ordre, et ce que chaque étape produit. Il fonctionne sur un système à concevoir comme sur un existant à reprendre — y compris du code que personne chez vous n'a écrit.

TimAtlas est né de l'expertise de Timorga et des problèmes que rencontrent ses clients. Nous l'avons éprouvé sur notre propre production avant de le proposer : Steppium, notre solution agentique, a été conçue, produite et documentée avec TimAtlas. Et Timorga vous accompagne d'un bout à l'autre — cadrage, construction du référentiel, arbitrage de la route, puis la production elle-même.

La suite de cet article dit pourquoi il nous a paru nécessaire.

L'outil est là, et il est puissant

Il n'est plus question de savoir si l'IA va entrer dans la production logicielle : elle y est déjà. Dans la plupart des directions informatiques que nous rencontrons, une partie du code écrit cette année ne l'a pas été à la main. Nous prenons cette nouvelle pour ce qu'elle est — une bonne nouvelle. Timorga construit des solutions agentiques, et ce site est lui-même tenu par un agent.

Mais un outil puissant ne dispense pas de savoir s'en servir. L'IA met à disposition l'outil le plus puissant dont on ait disposé à ce jour ; sans contrôle ni maîtrise, on peut faire n'importe quoi.

Ce qui arrive quand la production n'est pas encadrée

Quatre symptômes reviennent dans presque tous les projets où l'IA produit du code sans référentiel pour l'encadrer. Ils n'apparaissent pas le premier mois — c'est ce qui les rend dangereux. Ils apparaissent ensemble, plus tard.

Des chemins parallèles, en masse. C'est le plus coûteux, et le plus difficile à voir venir. Face à un correctif, l'IA ajoute volontiers une implémentation nouvelle plutôt que de toucher à celle qui existe : c'est la voie la plus sûre pour elle, et elle est parfaitement invisible dans une revue de code qui ne regarde que les lignes ajoutées. Quelques semaines plus tard, la même fonction existe cinq fois et plus personne ne sait laquelle tourne réellement. Le jour où une règle métier change, on la change à un endroit sur cinq.

Rien de documenté. La documentation reste la tâche qu'on fera après, et qu'on ne fait jamais, parce que le code avance plus vite qu'elle. Au bout de quelques mois, le système n'est plus décrit nulle part : ni pour l'équipe qui arrive, ni pour l'auditeur qui demande, ni pour l'IA elle-même à qui l'on redemandera d'intervenir.

Rien de reproductible. Impossible de refaire le chemin qui a mené au résultat : ni de le vérifier, ni de le corriger à la racine, ni de l'appliquer ailleurs. Chaque correction repart de zéro et coûte le prix d'une découverte.

Plus rien de maintenable. Un volume de code produit bien au-delà de ce qu'une équipe peut relire, comprendre et reprendre. La vitesse initiale est réelle ; elle se paie ensuite, et plus cher.

Aucun de ces quatre points n'est un défaut de l'IA. Ce sont les effets d'un outil puissant employé sans cadre.

Maîtriser et contrôler : deux gestes, et il faut les deux

On emploie souvent les deux mots l'un pour l'autre. Ils désignent deux moments opposés du travail, et l'un ne remplace pas l'autre.

Maîtriser, c'est décider en amont ce qui doit être produit. L'IA ne part pas d'une consigne en langage naturel — une phrase qu'elle interprétera à sa façon — mais d'un référentiel que vous avez arbitré : le cadrage, les domaines fonctionnels, le modèle de données, les règles de gestion, le plan de développement. Elle exécute une intention établie, pas une intention devinée. C'est ce qui sépare un outil qu'on dirige d'un outil qu'on subit.

Contrôler, c'est vérifier en aval ce qui a été fait. Chaque chose produite est rattachée à ce qui la justifie et à la ligne qui la porte. Ce qui est fait, ce qui reste à faire, ce qui n'est couvert par aucun test : c'est mesuré, pas déclaré. Un item « implémenté » n'est pas un item « validé » — le référentiel ne confond pas les deux, et n'affiche pas un vert qu'il ne sait pas prouver.

Sans le premier geste, l'IA part où elle veut. Sans le second, vous la croyez sur parole.

Ce qui distingue un référentiel d'un document d'architecture

TimAtlas construit son référentiel. Il ne le devine pas, et il ne se contente pas de mettre en forme ce que vous lui dictez.

Rien n'y entre sans ce qui le fonde — une décision que vous prenez, ou la ligne de code qui la démontre. Et ce qu'on n'a pas pu établir est déclaré tel quel, pas comblé par une supposition plausible. C'est ce dernier point qui fait toute la différence : un document affirme ; un référentiel affiche ses sources et signale ses trous.

La route à parcourir suit la même règle. Coconstruite avec vous à partir de vos objectifs, elle se met à jour au fil du travail au lieu de vieillir dans un coin du serveur de fichiers.

Et sur du code que vous n'avez pas écrit

Parce qu'un référentiel se construit à partir de preuves, il se construit tout aussi bien sur du code que personne chez vous n'a écrit, y compris très ancien. Plus de 170 grammaires sont lues, du mainframe au web. Un langage est lu par sa grammaire, ou il est déclaré non supporté : jamais d'approximation silencieuse.

Autrement dit : que votre système soit à concevoir ou déjà là, le référentiel se construit de la même façon.

Parlons-en

TimAtlas n'est pas un outil qu'on vous livre avec un manuel. L'IA travaille, et vous tranchez — à chaque décision, accompagnés par Timorga.

Un système à concevoir, ou un existant à reprendre ? Écrivez-nous.