Expertise · Conseil numérique
Diagnostic sur des systèmes réels, pas sur des entretiens : nous lisons le code, nous mesurons la production avec des commandes que vous pouvez répéter et nous demandons le document source pour chaque affirmation. Le résultat est une liste de décisions avec qui décide de quoi, pas une présentation.
Déjà construitMetoda a fost aplicată integral pe noi înșine și rezultatele sunt în depozit, cu fișier și linie. Trei livrabile concrete: un registru al activităților de prelucrare a datelor verificat rând cu rând pe producție, cu ce nu s-a putut confirma marcat „neverificat” și opt puncte lăsate explicit în decizia proprietarului; un audit de accesibilitate și performanță care declară de la început ce NU a putut măsura, cu cinci limitări enumerate, și care nu revendică niciun nivel de conformitate; și un registru al dovezilor pentru afirmațiile publice, care a eliminat trei premii inexistente ce circulaseră între documente interne fără ca nimeni să ceară originalul. Consultanța specializată pe adoptarea AI și instruirea echipelor are pagină proprie și se completează cu aceasta, nu o dublează.
Les décisions techniques les plus coûteuses ne se prennent pas sur de fausses informations. Elles se prennent sur des informations qui étaient vraies il y a dix-huit mois. Un document interne reprend un chiffre d’un autre, le troisième cite le deuxième, et la chaîne se rompt exactement là où personne n’a demandé l’original. C’est pourquoi la première partie de notre travail n’est pas la stratégie, mais la vérification.
J’ai appliqué la méthode sur nous-mêmes avant de la vendre. Nous avons construit un registre des preuves pour chaque affirmation publique sur notre propre site, avec la règle qu’une affirmation a une ligne avec le document primaire, pas avec le document qui la répète. Résultat : trois prix que nous affichions n’existaient pas — les programmes respectifs n’existent pas ou n’ont pas eu l’édition invoquée. En revanche, une distinction réelle, que la recherche publique ne pouvait pas confirmer en deux heures, a été éclaircie en une minute avec l’e-mail original. C’est la différence entre chercher et demander l’original.
La deuxième partie concerne la mesure, avec des commandes que chacun peut répéter. Nous avons découvert que trente pages de notre propre site avaient 105 mots chacune, dont 104 identiques — le seul mot propre à chaque page était le nom du domaine. Cela ne venait pas d’une opinion sur un contenu mince, mais d’une comparaison d’ensembles de mots sur le corps des pages extraites de la production. Un chiffre comme celui-là clôt une discussion qui, autrement, dure des mois.
La troisième partie est ce que nous faisons du résultat. Nous ne livrons pas une présentation avec des recommandations, mais une liste de décisions, chacune avec son responsable. Dans notre propre registre, huit points sont restés explicitement à la charge du propriétaire — de l’existence réelle d’une adresse e-mail déclarée publiquement, jusqu’à l’alignement de deux positions contradictoires que nous avions publiées à des endroits différents. Un consultant qui les aurait « résolus » seul aurait produit un document plus beau et une organisation tout aussi exposée.
Ce que cela comprend
Un registre avec une affirmation par ligne : document primaire, date, où il se trouve, s’il est publiable. Le document qui répète l’affirmation ne compte pas comme source. Appliqué à nous-mêmes, le registre a éliminé trois prix inexistants et a confirmé trois prix réels, dont un grâce à un e-mail original trouvé dans les archives — une source privée, montrable sur demande, qu’aucune recherche publique ne pouvait produire.
Les commandes de vérification font partie du livrable, afin que chacun puisse les répéter sans nous. Quand le document et la mesure ne sont pas d’accord, la mesure a raison : lors de la préparation de ce travail, j’ai trouvé un document interne qui déclarait un fichier d’environ 16 % plus petit qu’il ne l’était, et un schéma d’infrastructure qui décrivait un serveur dont nous étions déjà partis.
Dans notre audit d’accessibilité et de performance, la section des limites vient avant les résultats et énumère cinq éléments : les indicateurs de rendu que l’outil n’exposait pas, l’activation au clavier que l’automatisation ne pouvait pas reproduire fidèlement, l’absence de tests avec lecteurs d’écran, l’impossibilité d’émuler la préférence de réduction des mouvements et le manque de données de terrain. Les conclusions déduites sont marquées comme déductions, et non comme observations.
Le même audit ne contient aucun niveau de conformité déclaré, parce qu’un audit complet exige des tests avec de vrais lecteurs d’écran, sur de vrais appareils, avec des utilisateurs — rien de tout cela n’avait été fait. Ce qu’il contient, ce sont des constats individuels, chacun avec le critère pertinent, ordonnés de manière à pouvoir prioriser le travail. Trois blocages comptés, le reste : des améliorations.
Fait technique tiré de notre code : publiable, avec la ligne. État réel du projet : publiable, avec la vraie raison, pas avec l’euphémisme. Résultat commercial — clients, pourcentages d’amélioration, volumes : non publiable sans mesure et sans l’accord du client. Comparaison de type « premier » ou « meilleur » : non publiable sans critère et sans date. Cette grille s’applique avant d’écrire une ligne, pas à la relecture.
La politique publiée et l’implémentation ne doivent pas diverger, et la divergence est difficile à voir de l’intérieur. Exemples tirés de notre propre audit : la page promettait l’anonymisation de l’adresse IP, et le code l’envoyait intégralement dans une notification ; le délai de conservation déclaré publiquement n’était appliqué par rien. La règle qui en découle : si une modification de code change ce qui est collecté, à qui cela arrive ou combien de temps cela est conservé, le texte publié est modifié dans le même temps.
Un bon pilote a une entrée claire, une sortie claire, un critère numérique décidé à l’avance et un moyen d’arrêt qui ne coûte pas. Nous écrivons explicitement ce que le système n’a pas le droit de faire et comment il transmet à un humain. Si le diagnostic conclut que la bonne réponse est « ne construisez pas cela maintenant », nous l’écrivons avec la même explicitité — c’est la livraison la moins chère possible.
Un rapport qui n’arrive à personne est équivalent à un rapport qui n’existe pas. Dans un système propre, un rapport quotidien a été mort pendant onze jours alors que la tâche planifiée se déclenchait correctement — la commande utilisée échouait en silence. Nous examinons explicitement cette classe de défauts, car elle n’apparaît dans aucune liste d’exigences et ne déclenche aucune alarme.
Chaque point non résolu reçoit une ligne : ce que c’est, pourquoi cela compte, qui décide. Dans notre propre registre, huit points de ce type sont restés ouverts. Le conseil qui les résout seul produit un document plus lisse et une organisation tout aussi exposée.
À quoi cela ressemble
Tout ce que vous dites publiquement ou en interne sur les capacités, les résultats, les partenaires et les certifications entre dans une liste. Pour chacun, nous demandons le document primaire. Nous livrons : le registre avec les affirmations confirmées, celles infirmées et celles restées sans source, avec la recommandation pour chacune.
La production est vérifiée directement — en-têtes, temps, contenu, comportement aux limites — et le code est lu. Nous livrons : les mesures avec la commande exacte à côté, ainsi que la liste des endroits où la documentation et la réalité ne sont pas d’accord.
Les limites de la méthode entrent dans le rapport avant les conclusions. Nous livrons : la liste de ce qui n’a pas pu être mesuré et pourquoi, ainsi que ce qu’il faudrait pour que ce soit possible — outil, accès ou autorisation.
Les constats sont ordonnés selon l’effet et le coût de remédiation, les bloquants étant comptés séparément. Nous livrons : la liste ordonnée, avec ce que chaque point remédie exactement et comment la remédiation est vérifiée.
Un parcours, un critère numérique décidé à l’avance, une voie d’arrêt. Nous livrons : la définition du pilote, le critère d’acceptation et la liste des décisions restantes, chacune avec le nom de celui qui la prend.
Les données
Les questions que pose toute personne ayant un délégué à la protection des données — posées ici avant qu'il ne les pose.
Un cas
La situation
Un site de présentation affichait plusieurs distinctions. Personne ne les avait remises en question : elles apparaissaient dans des matériaux internes, dans des présentations et dans les textes des pages, et chaque document semblait s’appuyer sur un autre.
Ce que nous avons construit
Nous avons construit un registre avec une affirmation par ligne et une seule exigence : le document primaire, pas le document qui répète l’affirmation. Pour chaque distinction, nous avons cherché la source originale — l’annonce de l’organisateur, l’article de presse à la date de l’événement, la communication directe de celui qui l’a attribuée.
Ce qui en est sorti
Trois distinctions n’avaient aucune source : les programmes invoqués n’existaient pas ou n’avaient pas eu cette édition. Elles ont été retirées. Trois étaient réelles et sont restées, avec leurs sources publiques. La quatrième, que la recherche publique ne pouvait pas confirmer en deux heures, a été clarifiée en une minute avec l’e-mail original de celui qui l’avait attribuée — une source privée, montrable sur demande, parce que l’organisateur ne publie pas la liste des gagnants pour ce format. D’autres affirmations du type nombre de clients ou années de rentabilité sont aussi restées sans confirmation ; elles ont été marquées comme non publiables jusqu’à la vérification dans les registres de l’entreprise.
Ce que le cas ne dit pas
La chaîne ne s’est pas rompue à cause d’une invention délibérée. Un document a repris un autre, et le troisième a cité le deuxième comme source — elle s’est rompue exactement là où personne n’a demandé l’original. C’est pourquoi le registre n’est utile que s’il reste à jour : à la première nouvelle affirmation ajoutée sans ligne dans le registre, le processus recommence.
Questions
L’autre page parle de l’adoption de l’IA dans l’équipe : analyse des processus répétitifs, ateliers sur des exemples réels et un pilote construit ensemble. Celle-ci parle de diagnostic et de décision, que la réponse implique ou non l’IA. Elles se complètent : un diagnostic peut conclure que le problème n’est pas l’absence d’un assistant, mais le fait que le formulaire de contact perd des demandes. Vous pouvez commencer par l’un ou par l’autre — mais si vous ne savez pas ce qui vous fait mal, commencez par le diagnostic.
Des choses gênantes, publiées telles quelles. Trois prix affichés qui n’existaient pas, parce qu’un document interne les avait repris d’un autre sans que personne ne demande l’original. Le formulaire de contact renvoyait 500 et perdait des demandes sans trace, parce que l’accréditation du canal de notification avait été révoquée et que personne ne regardait. Une route qui pouvait initier un appel téléphonique vers n’importe quel numéro, anonymement. La page promettait l’anonymisation de l’adresse IP, et le code l’envoyait entière. Et trente pages qui avaient 104 mots identiques sur 105 entre elles.
Parce que le livrable contient les commandes, pas seulement les conclusions. Une affirmation que le client peut vérifier lui-même, avec une commande du rapport, ne peut pas être complaisante — elle se révèle fausse dès la première exécution. Et lorsque nous ne pouvons pas vérifier quelque chose, nous écrivons « non vérifié », ce qui est une conclusion valide. Nous l’avons utilisée huit fois dans notre propre registre.
Oui, et c’est la livraison la moins chère que nous puissions faire. Un exemple de notre propre travail : nous avions prévu de rediriger 73 pages générées vers des pages considérées comme « principales ». La mesure a montré que les pages de destination étaient elles-mêmes légères — 105 mots, dont 104 communs. La conclusion n’a pas été « on redirige plus vite », mais « on ne redirige pas un contenu léger vers un contenu encore plus léger ; on répare d’abord la destination ». La redirection a été conditionnée par la réécriture de la destination.
Nous disons ce que l’on peut conclure sans elles et ce que l’on ne peut pas. Dans notre audit de contenu, nous n’avons pas eu accès à la console de recherche, à l’analyse ni aux données de ventes — nous n’avons donc pas déclaré de trafic, de conversion ou de cannibalisation observée, même si c’étaient précisément les conclusions qui auraient sonné le plus convaincant. L’ordre correct est resté écrit dans le rapport : d’abord les données, puis la décision, pas l’inverse.
Nous livrons un rapport avec une constatation par ligne, les commandes de vérification et une liste de décisions avec propriétaire. Si vous voulez aussi une présentation pour une réunion, nous la faisons — mais ce n’est pas le livrable, c’en est un résumé. La différence compte, parce qu’une présentation ne peut pas être vérifiée, alors qu’un rapport avec des commandes, oui.
Autant qu’il faut pour que les affirmations du rapport aient un fichier et une ligne. En pratique, cela signifie lire les routes une par une et demander, pour chacune, qui l’appelle et ce qu’elle fait lorsque la vérification ne peut pas décider. Un outil automatique voit une route qui renvoie une erreur à une requête vide et passe à autre chose ; en la lisant, on voit que plus personne ne l’appelle et qu’elle est ouverte.
Non. Nous ne sommes pas des auditeurs accrédités, nous n’émettons pas de certificats et nous ne signons pas d’attestations de conformité. Ce que nous livrons, c’est une analyse technique avec des preuves vérifiables, utile pour décider et réparer — pas pour satisfaire une exigence formelle qui nécessite un organisme accrédité. Si c’est ce qu’il vous faut, il vaut mieux le savoir maintenant.
Ne produit pas de prévisions de revenus ou de trafic — nous n’avons pas de base pour cela et nous n’inventons pas. Ne compare pas des fournisseurs sur la base des chiffres qu’ils publient ; si nous n’avons pas nous-mêmes effectué la mesure, nous écrivons qu’il s’agit d’un chiffre déclaré, et non mesuré. Ne prend pas les décisions commerciales à votre place. Et ne produit pas un document qui semble complet en couvrant avec des formulations prudentes les endroits où nous ne savons pas — un audit vague est une façon de ne rien dire.
18 d'entre elles sont du code et des fichiers de nos dépôts. Nous n'en publions ni le nom ni la ligne : réunies sur une seule page, elles décriraient trop précisément comment sont construits des systèmes qui ne sont pas seulement les nôtres. Nous les parcourons avec vous, dans le dépôt, sur demande — la vérification reste possible, elle se fait simplement lors d'un échange.
Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.