La couverture ne devrait pas dépendre d'un cycle de publication

Il y a dans une exploitation criminalistique un moment que personne n’écrit dans le manuel de procédure. Un analyste ouvre une extraction, tombe sur une application qu’il ne reconnaît pas, et vérifie si son outil la prend en charge. Ce n’est pas le cas. La donnée est là, entièrement présente, dans une base de données dont il voit le nom de fichier. Et la réponse à la question de savoir si elle peut être lue est : pas ce trimestre.

Ce moment est en général traité comme un problème de support. Quelqu’un ouvre un ticket. L’éditeur l’ajoute peut-être à un arriéré, une version arrive peut-être dans six mois, l’application est peut-être assez populaire régionalement pour mériter le temps d’un ingénieur, et peut-être pas. Pendant ce temps, la procédure a ses délais.

Je voudrais soutenir que ce n’est pas un problème de support. C’est une propriété structurelle de la façon dont le secteur a choisi de fonctionner, et une fois qu’on le voit ainsi, beaucoup d’irritations quotidiennes dans un laboratoire se révèlent avoir une seule cause.

La décision est prise ailleurs

Tous les outils d’analyse criminalistique majeurs fonctionnent de la même façon. Quelqu’un, chez l’éditeur, rétro-conçoit le format de stockage d’une application, écrit un parseur, le teste, et le livre dans une version. L’analyste reçoit le résultat de ce travail sous forme de capacité.

C’est une ingénierie réellement difficile et les gens qui la font la font bien. Le problème n’est pas la compétence. Le problème est que cela place la décision la plus lourde de conséquences d’une exploitation, à savoir quelles données peuvent être lues, entre les mains de quelqu’un qui ignore que l’affaire existe.

Cette personne prend une décision commerciale raisonnable. Elle regarde combien de clients rencontreront cette application, à quel point son format est stable, ce que l’ingénierie coûtera. Une messagerie à deux cents millions d’utilisateurs mérite évidemment l’effort. Une plateforme sociale régionale à quatre cent mille utilisateurs, concentrés exactement dans la région où opère votre groupe criminel, constitue un dossier économique bien plus difficile. Du point de vue de l’éditeur, renoncer à l’implémenter est correct. Du vôtre, l’extraction en main, c’est toute l’affaire.

Les versions constituent la plus grande moitié du problème

L’histoire de l’application non prise en charge est celle qu’on raconte, mais elle minimise le sujet. L’échec le plus fréquent est plus discret : une application prise en charge dont l’organisation du stockage a changé.

Une application se met à jour. Elle réorganise une table, déplace un fichier, modifie l’encodage d’un horodatage. Le parseur avait été écrit pour la version précédente et ne renvoie plus rien, ou pire, renvoie quelque chose de plausible et faux. L’outil signale l’application comme prise en charge, ce qu’elle est, et l’analyste doit remarquer que la sortie est maigre.

Les cycles de publication des applications se comptent en semaines. Ceux des outils de criminalistique se comptent en mois. Cet écart ne se referme jamais, et ce n’est la faute de personne. C’est de l’arithmétique.

Ce que cela coûte, dans les termes qui comptent

Le coût n’apparaît pas comme une exploitation ratée. Il apparaît comme une réduction de périmètre, discrètement.

Un analyste qui dispose de trois semaines et de quarante scellés ne passe pas deux jours à lire manuellement une base SQLite inhabituelle avec un éditeur hexadécimal ouvert à côté, même s’il le pourrait. Il exploite ce que l’outil a décodé, rédige le rapport là-dessus, et mentionne le reste comme non analysé. C’est une décision professionnelle défendable. C’est aussi ainsi qu’une preuve qui existe, sur un appareil que le service détient déjà, dans une affaire déjà ouverte, finit par n’être jamais regardée.

Multipliez par une charge de travail et vous obtenez le chiffre qui préoccupe réellement les directeurs de laboratoire : la proportion des données saisies qui n’est jamais exploitée. Ce n’est pas un échec de tri. C’est un échec de couverture requalifié en tri.

L’alternative est inconfortable mais simple

Si le goulet d’étranglement tient à ce que les parseurs sont écrits par un éditeur, à l’avance, pour les applications qu’il a choisies, alors la correction consiste à cesser d’exiger qu’un humain chez un éditeur les écrive à l’avance.

C’est désormais techniquement faisable d’une manière qui ne l’était pas il y a cinq ans. Reconnaître à quoi sert une base de données inhabituelle, ce que contiennent ses tables et comment elles se rattachent aux concepts avec lesquels travaille un enquêteur, conversations, contacts, localisations, relève d’un raisonnement portant conjointement sur des chemins de fichiers, un schéma et du contenu. C’est exactement le type de tâche que les modèles génératifs traitent remarquablement bien et que les classifieurs ne traitent pas.

L’objection évidente est la bonne. On ne peut pas laisser un modèle décider de l’interprétation d’une preuve et se contenter de lui faire confiance. Alors ne le faites pas. Générez le mapping, validez-le structurellement, exécutez-le sur un échantillon des données réelles, et montrez à l’analyste un aperçu d’enregistrements véritables avant toute application. Si le mapping a mal compris la source, cela se voit immédiatement, parce que l’aperçu est incohérent. L’analyste l’accepte, le corrige dans un éditeur visuel, ou le jette.

Ce qui change n’est pas le niveau d’exigence. L’analyste vérifie toujours, et rien n’entre dans un rapport sans contrôle. Ce qui change, c’est qui fait le travail de première compréhension, et quand il peut avoir lieu. Il peut avoir lieu le jour où l’affaire en a besoin plutôt que le trimestre où un éditeur l’a planifié.

Pourquoi cela mérite d’être dit

Chaque laboratoire avec lequel j’ai échangé a une version de la même histoire, et chacun la raconte comme s’il s’agissait d’un désagrément local. Ce n’est pas local. C’est la même contrainte dans chaque service de chaque pays, et elle existe à cause d’un choix d’architecture que tout le secteur a fait tôt et n’a jamais réexaminé.

Le nommer change ce que l’on demande. Un service qui pense avoir un problème de support demande à son éditeur des publications plus rapides, ce que personne ne peut accorder. Un service qui reconnaît un problème structurel pose une autre question : que faudrait-il pour que la couverture cesse d’être quelque chose que nous attendons.

C’est la question à laquelle VERA a été construit pour répondre, et c’est pourquoi je préfère défendre la thèse plutôt que décrire le produit.