Aller au contenu
[ Cyrille Liétard ]
[ PL. 08 ]Déroulé d’une mission

La méthode

Cinq phases, dans cet ordre. Chacune produit un document ou un objet que vous gardez, y compris si la mission s’arrête là. Ce qui suit n’est pas un argumentaire : c’est le détail de ce qui se décide à chaque étape, de ce qui peut mal tourner, et de la manière dont je l’évite.

Coupe H—H

01
[ UN ÉCHANGE ]

Le relevé

On regarde ce qui existe : vos outils, vos fichiers, la tâche qui vous coûte le plus cher. Je ne vous demande pas ce que vous voulez comme technologie, je vous demande ce qui vous fait perdre du temps.

Une demande arrive presque toujours déjà habillée en solution — « il nous faudrait un agent conversationnel », « on voudrait de l’IA sur nos documents ». C’est un symptôme, pas un diagnostic. Le relevé sert à retrouver le problème sous la solution proposée.

[ CE QUI S’Y DÉCIDE ]

  • Le périmètre réel : la tâche précise qui se répète et qui coûte, pas le domaine entier.
  • Ce qui ne sera pas traité, et pourquoi — c’est souvent la moitié du bénéfice de l’échange.
  • Qui, chez vous, connaît vraiment le processus. Ce n’est presque jamais la personne qui a lancé la demande.

[ CE QUI PEUT MAL TOURNER ]

Repartir avec l’énoncé tel qu’il a été formulé. On construit alors exactement ce qui a été demandé, et personne ne s’en sert : l’outil répond à une reformulation du symptôme.

[ COMMENT JE L’ÉVITE ]

Je ne parle pas technologie au premier échange. Je demande à voir les fichiers réels, les copier-coller d’un outil vers un autre, la tâche qu’on garde pour le vendredi soir. La note de synthèse vous renvoie ce que j’ai compris, dans mes mots : si c’est faux, on le découvre là, avant qu’une ligne ne soit écrite.

Livrable
Une note de synthèse : ce que j'ai compris, et ce qui me manque encore.
Votre part
Une heure de votre temps, et l'accès à personne — juste une conversation.
Planche 08.01Éch. 1:1
02
[ SELON L'AMPLEUR ]

Le programme

Je liste les usages possibles et je les classe par impact réel et par faisabilité. Certains sont écartés à ce stade, et je vous dis pourquoi. C'est souvent la partie la plus utile.

Entre le moment où l’on sait ce qui fait mal et celui où l’on construit, il y a une décision d’ordre : par quoi commencer. C’est la décision la plus rentable du projet, et c’est celle qu’on saute le plus souvent.

[ CE QUI S’Y DÉCIDE ]

  • Les usages retenus, ceux qui attendent, et ceux qui sont écartés — chacun avec son motif : technique, juridique, ou simplement un gain qui ne paie pas la complexité.
  • La frontière entre ce qui relève d’un moteur déterministe et ce qui justifie un modèle.
  • Ce qui se fait en premier : un seul chantier, nommé.

[ CE QUI PEUT MAL TOURNER ]

Le catalogue. Vingt idées séduisantes, toutes également possibles sur le papier, aucune engagée. Un document de ce genre se range dans un tiroir et n’en sort plus.

[ COMMENT JE L’ÉVITE ]

Chaque usage est classé sur deux axes seulement — l’impact constaté chez vous et la faisabilité réelle — et le document se termine par une seule chose à faire ensuite. Il est écrit pour être autonome : vous le gardez, et il reste lisible par un autre prestataire que moi. C’est la garantie que la valeur du programme ne dépend pas de la suite qu’on lui donne.

Livrable
Un plan d'action chiffré et séquencé, avec ce qui se fait en premier et ce qui attend.
Votre part
Une réunion de restitution. Vous repartez avec le document, que vous alliez plus loin avec moi ou non.
Planche 08.02Éch. 1:1
03
[ COURT ]

L'esquisse

On construit la plus petite version qui prouve ou réfute l'idée, sur vos données réelles. Pas une maquette : quelque chose qui tourne. Si ça ne marche pas, on l'apprend ici, pas après six mois.

Un modèle qui répond correctement à dix questions préparées ne dit à peu près rien de son comportement sur les cas tordus. Or les cas tordus sont la matière quotidienne d’un métier réglementé.

[ CE QUI S’Y DÉCIDE ]

  • Si l’idée tient sur vos données réelles, avec leurs abréviations maison, leurs pièces mal scannées et leurs exceptions.
  • Le niveau de qualité atteignable, mesuré, et le coût de chaque point supplémentaire.
  • S’il faut continuer. Un arrêt à ce stade est une réussite de la méthode, pas un échec du projet.

[ CE QUI PEUT MAL TOURNER ]

La démonstration qui marche et le système qui ne marchera jamais. Elle se reconnaît à ce qu’elle a été jouée sur un jeu d’exemples choisi pour bien se comporter.

[ COMMENT JE L’ÉVITE ]

L’esquisse est éprouvée d’abord sur les cas que l’on préfère habituellement ne pas montrer. La mesure qui l’accompagne dit ce que le prototype rate, pas seulement ce qu’il réussit, et elle est écrite avant de connaître le résultat. Le testeur est une personne de chez vous, pas moi.

Livrable
Un prototype jouable, et une mesure honnête de ce qu'il fait et ne fait pas.
Votre part
Un jeu de données représentatif, et une personne de chez vous pour le tester.
Planche 08.03Éch. 1:1
04
[ PAR ÉTAPES LIVRÉES ]

L'exécution

Le développement, par itérations que vous voyez tourner. Les tests sont écrits en même temps, pas après. La conformité est traitée dans le code, pas dans une annexe.

C’est ici que se prennent les décisions coûteuses à défaire : le schéma de données, la place exacte de la validation humaine, la frontière entre le déterministe et le probabiliste. Tout le reste se corrige ; celles-là se paient.

[ CE QUI S’Y DÉCIDE ]

  • Le schéma de base de données, qui survivra à l’interface et probablement au modèle.
  • Où une personne doit cliquer, et ce qui ne part jamais sans ce clic.
  • Ce qui est journalisé, combien de temps, et qui peut le lire.

[ CE QUI PEUT MAL TOURNER ]

L’effet tunnel — des semaines sans rien de visible, puis une livraison qui ne ressemble pas à ce qui avait été compris. Et son jumeau : la conformité traitée en annexe, rédigée à la fin, quand le schéma ne peut plus changer.

[ COMMENT JE L’ÉVITE ]

Chaque étape se termine par quelque chose que vous voyez tourner sur vos données. Les tests s’écrivent avec le code, pas après. Les obligations — minimisation, traçabilité, information des personnes concernées — sont des contraintes du code : une donnée qui ne devrait pas être là ne peut pas être écrite, et pas seulement ne devrait pas l’être.

Livrable
Le logiciel, en production, avec sa documentation et ses tests.
Votre part
Un point régulier, et une validation à chaque étape livrée.
Planche 08.04Éch. 1:1
05
[ CONTINU ]

L'exploitation

Supervision, correctifs, évolutions. Je reste l'interlocuteur : ce n'est pas transmis à une équipe de support qui découvrira votre dossier.

Un logiciel en production n’est pas un objet livré, c’est un objet vivant dans un environnement qui bouge : vos données d’entrée changent, un fournisseur de modèle modifie son comportement, une règle métier devient fausse.

[ CE QUI S’Y DÉCIDE ]

  • Le niveau de suivi qui a du sens pour vous, et ce qu’il couvre exactement.
  • Ce qui déclenche une alerte, et qui est appelé quand elle se déclenche.
  • Le rythme des évolutions, pour que le système ne se fige pas au jour de sa livraison.

[ CE QUI PEUT MAL TOURNER ]

La dérive silencieuse. Le système répond encore, personne ne se plaint, et il a cessé d’avoir raison depuis des semaines. C’est la panne la plus chère parce qu’elle ne se signale pas.

[ COMMENT JE L’ÉVITE ]

Une supervision qui surveille la pertinence des sorties et pas seulement la disponibilité du service, des contrôles qui échouent bruyamment plutôt que de se dégrader en douceur, et un interlocuteur qui ne change pas : votre dossier n’est pas transmis à une équipe de support qui le découvrira.

Livrable
Un système surveillé, et quelqu'un qui répond.
Votre part
Nous convenons du niveau de suivi qui a du sens pour vous.
Planche 08.05Éch. 1:1
[ PL. 08.6 ]Ce qui ne se négocie pas

Quatre principes tenus

Ils ne dépendent pas du projet ni du client. Ils sont écrits ici pour qu’on puisse me les opposer.

  1. [ P.01 ]

    La machine prépare, vous décidez

    Aucune de mes livraisons n'envoie quoi que ce soit à un de vos clients sans qu'une personne ait cliqué. Le silence ne vaut jamais approbation.

  2. [ P.02 ]

    Je dis quand l'IA n'est pas la réponse

    Sur plusieurs projets, la meilleure solution était un moteur déterministe, pas un modèle. Un fournisseur qui sait où l'IA ne doit pas aller inspire plus confiance qu'un qui en met partout.

  3. [ P.03 ]

    Vos données restent identifiables uniquement chez vous

    Quand un modèle externe est nécessaire, ce qui sort est pseudonymisé, et la table de correspondance ne quitte jamais votre infrastructure.

  4. [ P.04 ]

    Je documente ce qui ne marche pas

    Mes projets portent des registres où mes propres sur-déclarations sont nommées, et des scripts qui font échouer une publication contenant une affirmation que je ne peux pas prouver.

[ PL. 08.7 ]Questions posées avant d’engager

Six questions, six réponses

Ce sont celles qui reviennent. Elles méritent mieux qu’une formule d’attente.

[ Q.01 ]Combien de temps avant de voir un résultat ?
Le premier livrable n’est pas un logiciel, c’est une note de synthèse, et vous l’avez à l’issue du premier échange. Vient ensuite l’esquisse : volontairement la plus petite chose qui tourne sur vos données réelles, pour que vous voyiez quelque chose fonctionner avant que l’essentiel du travail ne soit engagé. Je ne publie pas de délai type, parce qu’il dépend de l’état de vos données et du nombre de personnes à réunir chez vous ; il est fixé par écrit au moment du programme, une fois ces deux inconnues levées, et pas avant.
[ Q.02 ]Que se passe-t-il si l’IA ne convient pas à mon besoin ?
Je vous le dis, et cela arrive régulièrement. Sur plusieurs projets, la bonne réponse était un moteur déterministe, une reprise de processus ou une simple mise en ordre des données — pas un modèle. Le classement du programme sert précisément à écarter ces usages avant qu’ils ne coûtent quoi que ce soit. Si votre besoin relève entièrement de l’informatique classique, la mission continue sans modèle génératif, ou s’arrête au programme : dans les deux cas vous gardez le document, qui vaut par lui-même.
[ Q.03 ]Où sont hébergées mes données ?
Sur une chaîne européenne de bout en bout, volontairement limitée à trois maillons, avec des clés de chiffrement détenues en propre — sur votre infrastructure lorsque c’est possible, sur une infrastructure dédiée en Union européenne sinon. Quand le recours à un modèle externe est nécessaire, ce qui sort est pseudonymisé et la table de correspondance ne quitte jamais votre infrastructure. Les sous-traitants effectivement mobilisés sont nommés au contrat, au titre de l’article 28, et figurent au registre des traitements.
[ Q.04 ]Est-ce que je reste propriétaire du code ?
Oui. Le code écrit pour vous vous appartient : la cession des droits patrimoniaux est prévue au contrat, et le dépôt est hébergé sur un compte dont vous détenez l’accès dès le premier jour, pas à la fin. Deux réserves, dites d’emblée : les briques génériques que je réutilise d’un client à l’autre vous sont concédées sous licence d’utilisation perpétuelle, et les bibliothèques libres restent sous leur propre licence. Vos données, elles, et tout modèle ajusté sur vos données, sont à vous sans réserve d’aucune sorte.
[ Q.05 ]Comment se passe la reprise si je change de prestataire ?
Elle se prépare au premier jour, pas au dernier. Les dépôts, les secrets, les procédures de déploiement, le schéma de la base et la documentation d’exploitation sont tenus à jour pendant la mission, parce qu’ils servent pendant la mission. Une reprise n’est donc pas un geste de bonne volonté en fin de contrat : c’est une propriété du système. Concrètement, je remets les accès d’administration, la documentation et l’historique des décisions techniques, et je réponds aux questions de votre nouveau prestataire pendant une période convenue au contrat.
[ Q.06 ]Faut-il que mes équipes soient à l’aise avec l’informatique ?
Non, et la contrainte est même inverse : c’est au logiciel de s’adapter aux gens qui l’utiliseront. Les interfaces que je livre ressemblent à ce que vos équipes manipulent déjà, et les gestes qui comptent tiennent en un écran. La personne qui teste l’esquisse est d’ailleurs choisie de préférence parmi celles qui ne sont pas à l’aise : c’est elle qui révèle les vrais problèmes, et un outil qui lui résiste est un outil mal conçu, pas un utilisateur mal formé. Une prise en main est prévue au moment de la mise en service, et elle est courte par construction.

[ PHASE 01 — LE RELEVÉ ]

Tout commence par un échange d’une heure.