Comment fonctionne l'analyse

Nous cartographions votre logiciel à partir de son code, et chaque constat renvoie à la ligne exacte d'où il vient. Cette page explique comment nous le lisons, comment une reconstruction reste sûre, et ce qui est en place aujourd'hui.

Lire le code

Nous utilisons des analyseurs syntaxiques qui lisent chaque langage comme le fait son propre compilateur. Ils recensent les fonctions, les routes et les tables qu'ils parviennent à résoudre, ainsi que les appels qui les relient, et chaque élément renvoie à la ligne de code d'où il provient. Ce qu'ils ne parviennent pas à lire est consigné comme une limite, avec ce qu'il faudrait pour la lever. Quand un appel peut mener à plus d'un endroit, l'outil note son degré de certitude. Rien n'est deviné à cette étape. Le résultat est un ensemble de faits que vous pouvez vérifier ligne par ligne.

Des preuves utilisables ailleurs

Chaque constat est rattaché au fichier et à la ligne sur lesquels il repose, avec une empreinte permanente de ce fichier. Les résultats sont produits dans des formats publiés de l'industrie, vérifiés avec les validateurs officiels. Une autre firme peut les lire sans nous.

Où intervient l'IA

Un analyseur ne peut pas dire ce que le code fait pour votre entreprise, ni pourquoi une règle inhabituelle existe. Notre méthode utilise un modèle de langage pour le proposer, selon trois règles :

• Le modèle propose. Une vérification déterministe accepte ou rejette.
• Chaque affirmation renvoie à une ligne de code précise.
• Un modèle d'une autre famille vérifie que la ligne appuie l'affirmation.

Langages

Nous lisons Delphi, VB6 et TypeScript, y compris les schémas de base de données Drizzle. Un lecteur des procédures stockées SQL Server est écrit et en cours d'intégration à l'évaluation. Nous ajoutons un langage quand un mandat l'exige, et nous testons son analyseur avant d'accepter le mandat. Nous refusons Classic ASP, parce qu'aucun analyseur disponible ne le lit.

Garder une reconstruction sûre

Une reconstruction avance par étapes, et chaque étape peut être annulée. Votre système actuel continue de fonctionner jusqu'à ce que le nouveau soit prouvé sur votre propre activité enregistrée. La preuve principale est le rapprochement historique : nous rejouons cette activité dans l'ancienne version et dans la nouvelle, et nous comparons ce que chacune a répondu et ce que chacune a écrit dans la base de données. La bascule se fait ensuite par étapes : l'ancien système continue de fonctionner jusqu'à ce que le nouveau soit prouvé, et il reste disponible comme solution de repli jusqu'à ce que chaque étape soit prouvée. Si vous en avez besoin, nous comparons aussi côte à côte les sorties critiques sur le travail courant avant la fin d'une étape : facturation, paie, fin de mois, celles sur lesquelles vous ne pouvez pas vous tromper. La reprise se fait sur des copies de vos données, sur un réseau sans aucune sortie, pour qu'aucun test ne puisse joindre un client ou un fournisseur. Chaque écart est trié : le bruit, que nous traitons ; les changements voulus, que vous approuvez ; les défauts, qui bloquent l'étape. Une personne nommée répond de chaque changement.

Ce qui est en place

L'étape de lecture du code et les formats de preuve fonctionnent aujourd'hui. L'étape d'interprétation et la méthode pour tester une reconstruction sont conçues, mais pas encore construites. Quand nous établissons la portée de votre évaluation, nous vous disons exactement quelles parties elle utilisera.

Nous ne citons pas encore de taux de précision. Quand nous en aurons un, nous publierons la façon dont il a été mesuré.

Commencer