Des logiciels qui épousent nos façons de travailler : jusqu’où personnaliser ?

Deuxième volet d’une série sur les possibilités ouvertes par l’IA. Après « Avec l’IA, les projets sortent des cartons », la question devient celle du périmètre : que faut-il vraiment adapter ?

Imaginons une entreprise dont les interventions sont suivies dans un logiciel commun. Avant chaque déplacement, une coordinatrice rassemble pourtant les précisions dans un tableau, ajoute des notes, puis échange des messages pour confirmer une exception. Le processus officiel s’arrête là où commence une partie du travail réel. Cette situation est hypothétique : elle ne rapporte pas un cas client.

Le réflexe serait de demander un outil qui rassemble tout. Le détour par le tableau mérite d’abord une enquête plus modeste. Manque-t-il une fonction ? Existe-t-elle sans être connue ? Le paramétrage est-il incomplet ? Une formation résoudrait-elle la difficulté ? Ou conserve-t-on une validation qui n’a plus de raison d’être ? Construire trop vite peut donner une interface confortable à une complication inutile.

La personnalisation prend sa valeur lorsqu’elle préserve une pratique utile, facilite le travail et reste entretenue dans la durée. L’IA élargit les possibilités de réalisation ; elle ne décide pas à notre place de ce qui mérite un logiciel particulier.

Ce qui déborde du logiciel doit être compris avant d’être reproduit

Une particularité métier mérite d’être préservée lorsqu’on peut expliquer le service qu’elle rend. Dans notre exemple, une précaution propre à certains sites peut éviter une intervention mal préparée. La même utilité ne s’applique pas nécessairement à l’ordre des colonnes préféré par une personne, ni à une double saisie héritée d’une ancienne organisation.

Il faut distinguer le savoir-faire, la préférence et la contrainte héritée. Cette distinction demande de regarder une activité ordinaire et un cas difficile, avec les personnes qui les traitent. Quelle information change la décision ? Qui l’utilise ensuite ? Que perdrait-on en supprimant cette étape ? Les réponses donnent un contenu au besoin, au-delà de « notre métier est particulier ».

Une préférence peut compter pour l’appropriation d’un outil, sans devenir une règle imposée à tous. Une contrainte héritée peut encore protéger contre une erreur, même si son origine a été oubliée. L’enquête ne consiste donc pas à tout simplifier par principe, mais à rendre discutables les raisons de conserver ou de modifier une pratique.

Les standards apportent aussi une capacité collective

Une solution commune offre des repères que chaque entreprise n’a pas à reconstruire. Un vocabulaire partagé facilite la formation et les échanges ; des formats connus rendent les données plus faciles à transmettre ; un entretien mutualisé évite de porter seul chaque évolution. Ces apports peuvent peser davantage qu’une interface parfaitement ajustée à quelques habitudes.

Standardiser les données, les interfaces et les processus correspond cependant à trois choix différents. On peut conserver un identifiant commun et un format d’échange stable tout en adaptant une étape de validation. Une interface particulière peut présenter autrement les mêmes informations, sans créer une seconde définition du client ou de l’intervention. À l’inverse, deux logiciels visuellement proches peuvent abriter des règles incompatibles.

La question utile est donc : où une référence commune nous aide-t-elle, et où empêche-t-elle un travail nécessaire ? Une solution standard, même imparfaite, reste préférable lorsque ses écarts sont supportables, ses fonctions comprises et son entretien proportionné aux moyens disponibles. Il serait peu raisonnable de recréer un ensemble de fonctions courantes pour corriger une gêne limitée.

Les produits standard ne sont d’ailleurs pas nécessairement fermés aux adaptations. SAP documente pour S/4HANA des adaptations d’interface, des champs supplémentaires et de la logique métier. Cet exemple établit des possibilités dans le cadre décrit, pas leur disponibilité dans chaque version ou contrat, ni leur facilité de mise en œuvre. Il invite à examiner ce que permet réellement la solution utilisée avant de la remplacer.

Personnaliser peut consister à déplacer une frontière

L’adaptation forme un continuum. Le paramétrage modifie les choix prévus dans une solution. L’automatisation fait circuler une information ou déclenche une action entre des étapes. Une extension ajoute une capacité à un outil. Une interface spécifique propose un parcours adapté au-dessus de systèmes conservés. Une application autonome porte un fonctionnement plus distinct, avec un périmètre d’entretien plus large.

Ces degrés ne constituent pas une échelle de prestige. Dans notre situation hypothétique, rendre visible un champ existant peut suffire. Une connexion peut éviter une ressaisie. Une interface dédiée n’a d’intérêt que si le parcours le justifie. L’IA facilite l’exploration de ces options et la réalisation de premières versions ; une démonstration convaincante ne garantit pas leur bon fonctionnement dans tous les cas.

Le témoignage de Philippe Contal sur Influence éclaire cette question des frontières. Il cherche un outil correspondant à sa conception de la gestion de la relation et estime que les CRM qu’il rencontre ne répondent pas à ce besoin tel qu’il le formule. C’est son appréciation, pas la démonstration qu’aucun CRM ne sait gérer une relation. Il souhaite aussi préserver les données accumulées concernant environ 4 200 contacts.

Influence évolue avec ses besoins. Un arbitrage est particulièrement instructif : il a sorti la gestion des tâches pour conserver Todoist, connecté mais distinct. Personnaliser ne conduit donc pas forcément à tout intégrer dans une application. Cela peut consister à décider où s’arrête un outil et comment il échange avec un autre. La cohérence du travail tient alors à la qualité du passage entre les deux, pas au nombre de fonctions réunies derrière un seul écran.

Partir d’un usage précis, puis laisser les retours orienter l’évolution

Une adaptation reste plus facile à juger lorsqu’elle répond à un besoin formulé simplement. Pour PlugWit, Philippe Contal décrit une intention initiale : simplifier la création et la gestion des cartes de visite pour ses clients, en leur donnant davantage de liberté et d’autonomie. Selon son témoignage, plus de 50 personnes utilisent l’outil parmi ses clients, partenaires et amis. Ce nombre ne désigne pas 50 clients payants.

L’application évolue à partir des retours d’usage. L’IA y occupe une place limitée : elle reconnaît le texte de cartes de visite imprimées, c’est-à-dire transforme les caractères présents dans une image en texte exploitable. Cette fonction ne permet pas de qualifier l’ensemble du logiciel d’application fondée sur l’IA, ni d’en déduire des gains mesurés.

Avec Mnemory, le besoin initial est différent : réunir des sources diverses, des ressources, des preuves, des données et des réflexions pour les traiter ensemble, avec ou sans IA. Philippe explique qu’il peut accumuler ces éléments, les interroger et les croiser. Une trentaine de clients, partenaires et testeurs utilisent l’outil, d’après son témoignage ; ce n’est pas un décompte d’abonnements payants.

L’IA y est optionnelle. Philippe l’utilise beaucoup dans son travail quotidien, notamment en connexion avec Gmail, Influence, Todoist et Drive. Cet usage personnel ne signifie pas que toutes ces connexions sont des intégrations natives proposées à chaque utilisateur. Là aussi, les retours des utilisateurs orientent les évolutions.

Ces trois exemples proviennent de témoignages de Philippe Contal recueillis pour cet article. Ils renseignent des intentions et des arbitrages, sans constituer un audit technique ni une comparaison indépendante des solutions. La part de leur programmation réalisée avec l’aide de l’IA n’est pas documentée ici. Un logiciel conçu avec cette aide peut d’ailleurs fonctionner ensuite sans IA : l’assistance à la réalisation et les fonctions utilisées au quotidien sont deux sujets distincts.

Un outil ajusté doit rester compréhensible pour le collectif

Une application peut épouser une logique personnelle et devenir difficile à partager. Pour qu’elle serve un collectif, les mots doivent avoir le même sens : qu’appelle-t-on un contact actif, une demande validée, une ressource de référence ? Une exception doit pouvoir être expliquée et traitée sans créer une règle invisible pour les autres.

La participation des utilisateurs sert à éprouver ces définitions. Elle permet aussi de discuter les droits : qui consulte, modifie, valide ou supprime ? Les demandes d’évolution appellent un arbitrage explicite, faute de quoi chaque retour ajoute une option et rend l’ensemble moins lisible. Écouter les utilisateurs n’oblige pas à transformer chaque préférence en fonctionnalité.

L’entretien doit entrer dans cette discussion dès le début. La CNIL recommande d’intégrer la protection des données dès la conception et de vérifier les mises à jour. Ce repère s’applique au choix des accès et aux essais nécessaires ; il ne certifie aucune des applications évoquées. Le niveau de contrôle doit correspondre aux données et aux conséquences des erreurs possibles.

La maîtrise des données demande également de savoir ce qu’on peut récupérer, dans quel format et avec quelles relations conservées. Une liste de contacts exportée sans ses liens utiles peut être formellement récupérable et difficile à réutiliser. Une sauvegarde doit pouvoir être restaurée, rappelle la fiche de la CNIL consacrée aux sauvegardes. Les connexions, elles aussi, ont des règles d’accès et des conditions d’évolution.

L’autonomie signifie pouvoir choisir, comprendre et agir dans un périmètre connu. Elle ne signifie pas l’absence de dépendances. Hébergement, bibliothèques logicielles, services connectés et compétences d’entretien restent nécessaires selon l’architecture retenue.

Compter le coût du changement et celui du maintien par habitude

Multiplier les petites applications peut fragmenter le travail autant que le faciliter. Si chacune porte sa version des données et réclame ses propres corrections, l’effort d’entretien finit par dépasser le service rendu. Une adaptation limitée, bien reliée à l’existant, peut être plus utile qu’un ensemble d’outils autonomes séduisants séparément.

Le calcul économique doit comparer le même périmètre sur une même durée. Il inclut la conception, les abonnements, l’hébergement, l’intégration, les contrôles, la formation, la maintenance et le changement de solution. L’IA peut modifier certains efforts de réalisation, sans rendre les autres postes nuls ni garantir une économie globale.

Conserver l’existant a aussi un coût. Les ressaisies, la recherche d’informations dispersées et les erreurs de transmission mobilisent du temps, même lorsqu’aucune facture ne les isole. On peut les observer sur un processus précis avant de décider. Cette observation peut justifier une évolution ; elle peut aussi montrer qu’un meilleur paramétrage ou une simplification répond au problème.

Le choix ne se réduit donc ni au prix d’un abonnement ni à la rapidité d’une première version. Il porte sur un fonctionnement que l’entreprise accepte de faire vivre.

Cinq questions pour choisir une adaptation proportionnée

La grille suivante propose un support de discussion, sans score automatique. Chaque réponse doit conduire à un choix de périmètre et à une responsabilité explicite.

Question	Arbitrage à rendre
Quelle particularité utile voulons-nous préserver ?	Décrire le service rendu et décider quelles habitudes peuvent évoluer.
Une solution existante la couvre-t-elle par paramétrage ou extension ?	Vérifier les possibilités réelles avant de choisir entre adaptation limitée et développement.
Qui utilise, valide et fait évoluer l’outil ?	Nommer les responsables métier, les utilisateurs concernés et la personne qui arbitre les demandes.
Quel effort et quel coût acceptons-nous dans la durée ?	Fixer un périmètre soutenable, une durée de comparaison et un moment de réexamen.
Comment conservons-nous la maîtrise des données et des connexions ?	Préciser les accès, les exports utiles, les restaurations à éprouver et les échanges à entretenir.

Il est possible de conclure à un logiciel standard, à une extension, à une connexion mieux définie ou à une application spécifique. La bonne décision conserve ce qui fait la valeur du travail et accepte de faire évoluer le reste. Les possibilités nouvelles ouvertes par l’IA rendent cet arbitrage plus accessible ; elles le rendent aussi plus nécessaire.

Une fois l’outil adapté au travail, reste à décider ce que l’organisation veut améliorer grâce à lui. Ce sera la question du troisième volet : « Que voulons-nous faire de la puissance que l’IA nous donne ? »

Charger le lecteur Spotify

Ouvrir ce lecteur autorise une connexion à Spotify, qui peut recevoir des informations de navigation.