Applications non prises en charge : le goulet d'étranglement silencieux des laboratoires
Personne ne consigne le constat qu'il n'a pas fait. C'est pourquoi ce problème est invisible dans les statistiques d'un laboratoire.
Les indicateurs de laboratoire mesurent le débit : scellés traités, jours par exploitation, taille de l’arriéré. Ce qu’ils ne peuvent pas mesurer, c’est la preuve qui était présente, n’a jamais été lue, et n’est donc jamais devenue un constat.
Ce chiffre n’existe nulle part. Il ne le peut pas, puisque le consigner supposerait de savoir ce que contenait la partie que personne n’a ouverte. Mais il n’est pas petit, et sa première cause est les applications qu’un outil n’a pas décodées.
Quatre façons de devenir illisible
Elle est régionale. Une messagerie ou une application sociale comptant quelques centaines de milliers d’utilisateurs dans un pays n’est pas une priorité pour un éditeur qui vend sur quarante marchés. Elle peut être extrêmement pertinente si ce pays est celui de votre enquête.
Elle est récente. L’écart entre le moment où une application devient populaire et son apparition dans les notes de version d’un outil se compte en trimestres. L’adoption criminelle d’un nouveau canal se compte en semaines, et elle est souvent plus rapide que l’adoption légitime, parce que l’incitation à changer est plus forte.
Elle a changé. C’est la catégorie la plus importante et la moins discutée. Une application prise en charge publie une mise à jour qui réorganise son stockage, et le parseur écrit pour la version précédente renvoie des résultats partiels ou aucun. L’outil continue de lister l’application comme prise en charge. L’analyste doit remarquer que la sortie est plus maigre qu’attendu, ce qui suppose de savoir déjà à peu près à quoi s’attendre.
Elle n’a jamais été la priorité de personne. Applications de sport, de prise de notes, historiques de transport, applications de livraison, portefeuilles de paiement, mémos vocaux. Rarement centrales, parfois décisives, et individuellement jamais dignes du trimestre d’un ingénieur.
Pourquoi cela reste invisible
Trois choses empêchent ce sujet d’apparaître comme un problème dont quelqu’un serait responsable.
La première est que le rapport est exact. Un analyste qui écrit que certaines données applicatives n’ont pas été analysées a correctement documenté la limite. Rien dans une revue qualité ne le signalera.
La deuxième est que la règle informelle de périmètre est raisonnable. Exploiter ce que l’outil a décodé, exploiter ce que l’enquêteur a expressément demandé, mentionner le reste. Sous charge réelle, c’est la décision professionnellement correcte, et elle produit la même réduction de périmètre à chaque fois.
La troisième est que personne ne sait ce qui a été manqué. Un enquêteur qui n’apprend jamais qu’une conversation existait ne peut pas demander pourquoi elle n’est pas au rapport. L’absence est structurellement inobservable.
Ce que font réellement les analystes
Les bons font quelque chose, et cela ne passe pas à l’échelle.
Certains ouvrent la base à la main, en déduisent le schéma et écrivent une requête. Certains entretiennent une collection personnelle de scripts. Certains connaissent un collègue dans un autre service qui a déjà croisé cette application, et lui écrivent. Dans quelques laboratoires il y a une personne, en général une seule, connue pour accepter de faire cela, et sa file d’attente est le véritable goulet d’étranglement.
Chacune de ces variantes pose les deux mêmes problèmes. Elle coûte des heures que l’affaire n’a pas, et la compréhension produite n’est pas durable. Elle vit dans une tête ou dans un fichier de brouillon, et elle part avec la personne. L’analyste suivant, dans le service suivant, rencontre la même application six mois plus tard et recommence.
La forme d’une réponse
Si la contrainte tient à ce que quelqu’un doit comprendre un format de stockage inhabituel avant que son contenu ne soit lisible, il n’y a que deux sorties. Rendre cette compréhension moins coûteuse à produire, ou la rendre durable une fois produite.
Les deux sont disponibles, et elles se cumulent.
La produire à bas coût est désormais un problème traitable. Déterminer à quoi sert une base de données inhabituelle, à partir de son chemin, du nom de ses tables et de ses colonnes et d’un échantillon de son contenu, relève du raisonnement plutôt que de la reconnaissance de motifs, et c’est le type de tâche que les modèles actuels traitent remarquablement bien. Le résultat est un mapping : la description de la façon de lire cette source vers les champs qu’attend une visionneuse.
Ce résultat ne peut pas simplement être cru, et il n’a pas besoin de l’être. 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. Un mapping qui a mal compris la source produit un aperçu incohérent, ce qui saute aux yeux en quelques secondes. L’analyste l’accepte, le corrige dans un éditeur visuel, ou l’écarte.
Le rendre durable est la moitié la plus simple et la plus précieuse. Un mapping validé est un petit artefact qui ne contient aucune preuve, seulement la description de la façon de lire une structure. Il peut être partagé. Quand un autre laboratoire ouvre un scellé contenant la même application, il s’applique automatiquement.
C’est à ce moment que l’économie du problème change. Aujourd’hui, l’effort de comprendre une application est répété dans chaque service qui la rencontre, et perdu à chaque fois. Partagé, il est payé une fois.
L’affirmation dont il faut se méfier
Il existe une version de cet argument qui va trop loin, et la ligne mérite d’être marquée.
Le mapping automatique ne signifie pas qu’un analyste n’a plus jamais rien à regarder. Il signifie que la première compréhension est produite par le logiciel et que le rôle de l’analyste devient la revue plutôt que la construction. Certains mappings seront faux. Certaines sources sont réellement ambiguës, et aucun raisonnement sur un schéma ne dira ce que signifie une colonne nommée f4 dont le contenu est une suite d’entiers.
Ce qui change n’est pas l’exigence. C’est qui fait la première passe, et combien de temps un laboratoire l’attend. Au lieu d’un trimestre, cela prend quelques minutes, et le résultat est quelque chose que le service conserve.
VERA
VERA est un logiciel d'analyse criminalistique pour supports numériques saisis. Il structure une extraction Full File System brute, la rend consultable et interrogeable avec citation des sources, et fonctionne entièrement hors ligne sur votre infrastructure.
Demander une démonstrationÀ lire aussi
La recherche par mots-clés manque le langage codé, qui est le quotidien du travail sur les stupéfiants
Le vocabulaire des enquêtes est volontairement oblique, il varie d'un groupe à l'autre et il change avec le temps. Une recherche fondée sur la correspondance exacte est structurellement incapable de suivre.
Le volume de médias dans les affaires de protection de l'enfance : ce que le tri peut et ne peut pas faire
Les médias concentrent le volume et le coût de la revue, dans les affaires où ce coût est le plus lourd. Le tri automatisé aide sur l'arithmétique. Il ne supprime pas l'analyste, et il ne doit jamais être vendu comme s'il le faisait.