Une solution numérique ne commence pas par la technologie

En bref

• Avant de choisir un outil ou une IA, je cherche à comprendre le travail réel, pas celui du cahier des charges.
• Automatiser n'est pas supprimer l'humain : on automatise ce qui précède la décision, pas la décision elle-même.
• Cette méthode change aussi le chiffrage : on chiffre ce qu'il faut réellement construire, et on peut dire non.

Elle commence par comprendre ce qui se passe réellement sur le terrain.

Il y a une question que je pose avant de commencer à développer quoi que ce soit :

« Qu’est-ce qui se passe réellement aujourd’hui ? »

Pas :
« Quel outil voulez-vous ? »

Pas :
« Quelle IA souhaitez-vous utiliser ? »

Et même pas :
« Quelle fonctionnalité faudrait-il ajouter ? »

Je veux d’abord comprendre le travail réel.

Parce qu’entre ce qu’une organisation pense faire, ce qu’elle décrit dans un cahier des charges et ce qui se passe réellement lorsqu’une personne traite une situation, il y a souvent un écart.

C’est précisément dans cet écart que se trouve le travail de conception.

Je pars du problème, pas de la solution

Prenons un exemple très simple.

Une association me dit :

« Nous perdons beaucoup de temps à préparer nos dossiers de subvention. »

La réponse immédiate pourrait être :

« Il faut automatiser la rédaction avec une IA. »

Mais ce n’est pas encore une solution.

Avant de développer quoi que ce soit, je cherche à comprendre le processus.

Quels documents sont utilisés ?
Quelles informations faut-il retrouver ?
Lesquelles sont déjà disponibles ?
Lesquelles doivent être recherchées ?
Qui vérifie les données ?
À quel moment une personne doit-elle prendre une décision ?
Qu’est-ce qui doit absolument rester sous contrôle humain ?

On découvre alors parfois que le problème n’est pas réellement la rédaction.

Il peut être question de recherche d’informations, de classement documentaire, de vérification, de transmission entre plusieurs personnes ou simplement de reconstitution d’un historique.

Le bon outil dépend du problème réellement rencontré.

Je reconstitue le déroulement réel

Je prends une situation concrète et je la déroule chronologiquement.

Une demande arrive.
→ Une personne ouvre le dossier.
→ Elle cherche une information.
→ L’information n’est pas disponible.
→ Elle consulte plusieurs documents.
→ Une donnée doit être vérifiée.
→ Elle demande confirmation à quelqu’un.
→ Une décision doit être prise.
→ Le traitement peut continuer.

Ce déroulement permet de distinguer :

• ce qui peut être traité directement ;
• ce qui nécessite une recherche ;
• ce qui nécessite une vérification ;
• ce qui nécessite l’intervention d’une autre personne ;
• ce qui nécessite une décision.

Et ces différences changent complètement la solution à concevoir.

Je ne cherche pas à automatiser ce qui ne doit pas l’être

Automatiser n’est pas supprimer l’humain.

Si une étape nécessite une décision, l’objectif n’est pas nécessairement de faire prendre cette décision par une machine.

On peut plutôt automatiser ce qui précède :

• rassembler les informations ;
• rechercher les documents ;
• préparer une synthèse ;
• signaler une anomalie ;
• présenter les éléments nécessaires à la décision.

L’humain intervient alors au bon endroit.

La technologie ne remplace pas le fonctionnement métier.
Elle vient l’améliorer là où cela a réellement du sens.

Ensuite seulement, je conçois le système

Une fois le fonctionnement compris, je peux commencer à concevoir.

Problème identifié
→ informations dispersées

Besoin
→ retrouver rapidement les informations pertinentes

Solution possible
→ moteur de recherche documentaire spécialisé

Besoin complémentaire
→ éviter les réponses fondées sur des documents obsolètes

Solution
→ mécanisme de vérification et de traçabilité

Besoin humain
→ conserver la décision finale

Solution
→ validation humaine intégrée au processus

On passe ainsi de :
« Il nous faudrait une IA »

à :
« Voici précisément ce que le système doit faire, ce qu’il ne doit pas faire et à quel moment une personne doit intervenir. »

Cette méthode change aussi le chiffrage

Une fois le fonctionnement décomposé, je peux identifier les véritables unités de travail :

• analyser les sources ;
• structurer les données ;
• développer un module de recherche ;
• intégrer un traitement automatique ;
• prévoir les contrôles ;
• développer l’interface ;
• tester les scénarios réels ;
• corriger ;
• déployer.

On ne chiffre plus simplement :
« une application avec de l’IA ».

On chiffre ce qu’il faut réellement construire.

Et surtout, on peut dire non

Si une automatisation n’apporte pas suffisamment de valeur, je préfère le constater avant de la développer.

Si une fonctionnalité complique davantage le fonctionnement qu’elle ne le simplifie, elle doit être remise en question.

Si une IA n’est pas nécessaire, elle n’a pas besoin d’être ajoutée.

La technologie est un moyen. Pas le point de départ.

Du problème concret à la solution fonctionnelle

C’est finalement ce que je cherche à faire avec ServiceProi.

Comprendre.
Reconstituer.
Concevoir.
Développer.
Tester.
Ajuster.

Et seulement à la fin :

obtenir une solution qui fonctionne réellement dans le contexte pour lequel elle a été conçue.

C’est cela que j’appelle l’artisanat numérique.

Pas une solution standard plaquée sur un problème.

Une solution conçue à partir du problème réel.

Jean-Christophe
ServiceProi
serviceproi.fr

Pour aller plus loin : lancer le diagnostic ServiceProI ou découvrir les offres ServiceProI.