Notre méthode
Deux outils et une règle. Les outils récupèrent ce que fait un système et construisent son remplaçant à travers des points de contrôle. La règle : un modèle peut proposer, jamais décider.
Récupérer la spécification
La modernisation n'est presque jamais un simple transfert. Nous extrayons le système tel qu'il est, puis vos experts métier modifient les exigences : en conserver, en réécrire, en retirer, en ajouter. Cette décision, prise pour chaque comportement de chaque application, c'est le projet. Notre outillage existe pour la rendre explicite, révisable et traçable plutôt qu'implicite et perdue.
Un seul graphe pour tout le portefeuille
Le code source est analysé en arbres syntaxiques et en graphes d'appels avec Tree-sitter, puis compilé en graphe orienté. La détection de communautés regroupe le graphe en contextes délimités candidats. Les nœuds d'exigences sont écrits dans le même graphe à partir du code, des documents ou d'une liste d'exigences existante, de sorte que chaque étape suivante lit une seule structure.
Des dépendances qui refusent de feindre la préséance
L'ordre de construction ne vaut que ce que valent les arêtes de dépendance ; elles sont donc produites par couches. Les voisins structurels forment un ensemble de candidats peu coûteux à fort rappel. Un modèle statue sur chaque candidat : est-ce un vrai prérequis, dans quel sens, de quel type, avec quel degré de confiance et pourquoi. Chaque arête porte sa provenance, affirmée ou inférée, et un score de confiance. Les arêtes simplement thématiques, « toutes deux concernent la facturation », regroupent les exigences sans jamais les ordonner.
Un planificateur qui n'appelle aucun modèle
Le planificateur d'itérations est déterministe et fonctionne hors ligne. Il sélectionne les arêtes d'ordonnancement, détecte les cycles et les soumet à une personne plutôt que de les linéariser en silence, et dispose le travail en vagues topologiques. Mêmes entrées, même plan, à chaque fois, et le résultat se teste unitairement.
Des exigences comme comportements, non comme prose
Chaque exigence est rédigée comme un scénario Gherkin : étant donné une situation, quand quelque chose se produit, alors voici le résultat. Les règles d'affaires qui les sous-tendent viennent de trois sources, dans cet ordre de confiance : extraites du code patrimonial avec la ligne citée, extraites des documents existants, et dégagées en entrevue auprès des personnes qui font tourner le processus aujourd'hui. Un scénario dit d'où vient sa règle. Les mêmes scénarios pilotent le prototype en phase 1 et deviennent la suite d'acceptation en phase 2 ; rien n'est réalisé qui ne se rattache à l'un d'eux.
Des cibles non fonctionnelles, mesurées comme des comportements
Un système peut réussir tous ses scénarios et rester trop lent, illisible pour un lecteur d'écran ou impossible à restaurer. La phase 1 produit donc aussi une fiche de cibles non fonctionnelles : temps de réponse sous charge, accessibilité (WCAG 2.1 AA par défaut), contrôles de sécurité, disponibilité, sauvegarde et reprise, résidence des données, et langues officielles lorsqu'elles s'appliquent. Chaque cible a un seuil et la vérification automatisée qui le prouve, par exemple « 95 % des recherches répondent en moins de 800 ms avec 200 utilisateurs actifs, mesuré par un essai de charge ». Vous signez les cibles avec les scénarios. En phase 2, une cible manquée est un défaut, exactement comme un scénario qui échoue.
Trois points de contrôle humains, par conception
- Revue des exigences : confirmer, dédoublonner et lever les ambiguïtés de ce qui a été extrait, avec sa provenance.
- Revue des dépendances : confirmer les arêtes inférées avant que le plan soit final.
- Revue des livrables et capture de l'existant : revoir la spécification, les scénarios d'acceptation et les cibles non fonctionnelles, et prendre des enregistrements de référence pour les comportements qui restent inchangés.
L'étape humaine n'est pas une finition. En modernisation, c'est le pivot où l'existant devient la cible. La phase 1 se termine quand ce pivot est visible : un prototype sur données simulées, généré à partir du même contrat d'API que le système réel mettra en œuvre, de sorte que ce que vous approuvez à l'écran est ce à quoi la phase 2 est mesurée.
Construire à travers des points de contrôle
La réalisation s'appuie sur un gabarit versionné que nous maintenons comme produit interne : un cycle complet des exigences à la production installé dans chaque projet, avec 22 commandes, 14 ensembles de règles et une base de connaissances composable, pour que l'application n+1 hérite de chaque convention établie par l'application n. Le développement piloté par le comportement en est la colonne vertébrale : les scénarios Gherkin sont la source de vérité, et les définitions d'étapes qui les mettent en œuvre sont les tests que l'on scelle.
La chaîne est fixe : le document d'exigences passe un point de contrôle de revue avant le début de la conception ; les documents de conception sont générés à partir d'un profil approuvé ; les scénarios d'acceptation sont rédigés à partir des exigences ; le contrat d'API est la source unique de vérité pour que le code et les simulations ne puissent pas dériver ; une suite de tests est scellée avant le début de la réalisation ; le réalisateur fait passer ces tests et ne les modifie jamais ; et une étape de durcissement rejoue tout depuis un état propre sans se fier à aucune auto-déclaration.
Comment le prix fixe est établi
La soumission se compte, elle ne se devine pas. Notre estimateur lit ce que la phase 1 a produit : les scénarios et leur taille, les opérations d'API, les écrans, les entités de données, les intégrations, les données à migrer, les inconnues restantes et les cibles non fonctionnelles. Il chiffre chacun en jours-personnes à partir d'efforts unitaires réajustés à l'effort réel après chaque mandat, et ajoute trois lignes que la plupart des soumissions cachent : le soutien à votre recette à chaque jalon, une réserve pour corriger les défauts que la recette trouvera, et une contingence dimensionnée selon ce qui reste incertain. Un modèle peut proposer la taille d'un scénario en citant ses lignes ; le calcul s'exécute sans modèle, et une personne nommée signe la soumission. Mêmes entrées, même prix.
La méthode se mesure elle-même
Ce qu'il y a de plus utile dans le journal des modifications de la méthode, c'est la trace de ses propres erreurs. Un détecteur de dette structurelle a obtenu 22 % de précision sur une base de code réelle de 2 239 symboles ; le suivre aveuglément aurait supprimé une centaine de composants fonctionnels. Le correctif : un protocole à trois niveaux, analyse de graphe sans modèle, puis vérification textuelle mécanique sans modèle, puis jugement, par un modèle, seulement sur ce qui reste. Un décompte de dépendances qui ignorait les importations de types seuls était « un nombre faux avec assurance, non un nombre manquant » ; une passe de vérification compte désormais les vrais importateurs. Nous consignons ces ratés à l'interne parce qu'une méthode qui se méfie de sa propre sortie est celle qu'un vérificateur peut croire.
Ce que l'IA peut et ne peut pas faire
- Déterministe là où ça compte. L'ordre de construction, l'ordonnancement des dépendances et la vérification de parité s'exécutent sans aucun modèle.
- Chaque valeur extraite est ancrée. Un fait proposé doit citer la construction source exacte d'où il a été lu, et cette citation est vérifiée mécaniquement avant que le fait soit utilisé. Une valeur non étayée est rejetée par l'outillage, non crue.
- Défaillance sécuritaire. Ce qui ne peut être vérifié est marqué inconnu et acheminé à une personne. Le système ne devine pas et ne comble pas un vide en silence.
- Les humains tiennent les points de contrôle. Les exigences extraites, les décisions de dépendance et le choix conserver-ou-modifier sont approuvés par vos experts métier avant que quoi que ce soit soit construit.
- Votre code peut rester à l'intérieur de votre périmètre. L'analyse syntaxique, la construction du graphe et la planification s'exécutent entièrement hors ligne. Les étapes qui font appel à un modèle peuvent pointer vers un modèle à poids ouverts auto-hébergé au Canada. Nous avons exécuté cette configuration sur notre propre infrastructure.
La déclaration complète des étapes, des modèles, des flux de données et des points de contrôle se trouve à la page sur l'utilisation de l'IA, et nous la fournissons par écrit pour tout mandat.