Miser sur le bon outil (IA ou pas)

Il ne se passe pas une semaine sans qu’un nouvel outil IA ne sorte ou ne soit actualisé. Il est impossible de tout suivre et même si les investisseurs dépensent des millions, la réalité du marché va forcément faire redescendre tout le monde sur Terre. Comment choisir le bon outil logiciel quand tout change tous les 6 mois ?

Comme les plus technophiles d’entre vous, j’ai des comptes ouverts partout et accepte volontiers de tester plein de nouveaux services, mais un jour, il va bien falloir arrêter de tester et fixer des process pour vraiment travailler.

Quand un client demande quel outil utiliser pour tel ou tel besoin afin de rester dans la course et miser sur l’IA, c’est toujours très difficile de faire des préconisations. Non pas que les outils ne soient pas bons ou n’existent pas, mais le temps des clients n’est souvent pas du tout le même que celui des spécialistes tech.

Lorsqu’un client souhaite prendre un nouvel outil, il va vouloir le tester, former ses équipes, le brancher avec ses autres outils ou modifier ses process. Si c’est pour lui dire dans 6 mois qu’il y a un meilleur outil qui fait mieux, plus vite et moins cher, faut-il tout renverser et recommencer ? Ne pas recommander d’outil en attendant l’outil parfait n’est pas non plus la bonne approche.

On a donc ici plusieurs problèmes :

• Des technos qui évoluent trop vite pour le rythme de la majorité des entreprises ;
• La peur de faire le mauvais choix et d’être coincé ;
• L’impératif d’avancer malgré cet environnement incertain.

Le risque n’est pas de choisir un outil imparfait, c’est de rester paralysé ou de s’enfermer dans un mauvais choix. Les clients ont moins besoin de certitudes que d’un cadre pour naviguer l’incertitude.

On fait quoi alors ?

L’objectif est de limiter l’incertitude, de réduire les risques et de présenter une solution défendable et documentée. Cela permet de basculer de « choisir un outil » à « adapter une approche résiliente pour faire le bon choix d’outil ».

Diagnostic orienté solution

Cahier des charges est un mot qui fait peur. L’idée, c’est simplement de formaliser les usages pour éviter de prendre le problème à l’envers en choisissant d’abord la techno. Concrètement, lister :

• Flux de travail (qui réalise quoi, comment, quand, avec quelles données en entrée, en sortie) ;
• Contraintes métier (sécurité, contraintes légales, politique interne, criticité et continuité, compétences internes, outils legacy) ;
• Douleurs identifiées (coût, temps perdu, risque, répétitivité) ;
• Maturité digitale (Même s’il faut froisser quelques egos, il faut poser des limites).

Nécessaire VS annexe

« Tout » n’est jamais le bon choix lorsqu’on choisit les fonctionnalités. Il faut prioriser. Parce que tout bouge très vite, par rapport aux délais envisagés, qu’est-ce qui :

• Est vital et non négociable ;
• Est essentiel ;
• Est du confort ou du luxe (et qui va être reporté à plus tard peut-être…).

Les chefs de projet logiciels connaissent la méthode MoSCoW. C’est tout à fait ça.

Pour rappel, 80% des fonctionnalités ne sont jamais utilisées (Excel à 6000 fonctions, vous en utilisez combien ?). Il ne sert à rien de sur-spécifier même si tout avoir semble la bonne solution.

Et pour répondre à l’objection « tout est important », c’est simple. Il faut demander ce qui est le plus utile si on ne dispose que d’un mois et qu’on doit choisir 3 fonctionnalités. Une autre façon d’arbitrer consiste à mettre un prix sur chaque fonctionnalité (si on la développe ou l’achète) et à la comparer avec l’impact business.

Réduire les risques

Choisir un ERP fait peur. Les entreprises savent qu’elles vont se retrouver contraintes de travailler avec pendant de nombreuses années. Le risque est important. En cas de mauvais choix, il sera difficile et coûteux de changer. Ce n’est pas ici le même enjeu, mais on est sur des logiques similaires.

Dans notre cadre, l’idée est d’expliquer au client qu’on doit pouvoir changer et qu’on peut mesurer le risque lié au changement (du plus important au moins important) :

1. Réversibilité (est-ce facile de faire marche arrière ?) ;
2. Interopérabilité (standards, API, formats d’import / export) ;
3. Coût de la migration (durée, formation, process) ;
4. Niveau de verrouillage par le fournisseur ;
5. Pérennité du fournisseur et de son écosystème.

Ces critères sont à adapter en fonction de chaque projet. Actuellement, la réversibilité et l’interopérabilité m’apparaissent les critères les plus importants.

Si on est face à un problème de réversibilité, l’idéal est d’éviter de s’engager ou de se protéger en documentant un plan de sortie dès le départ (coût, données exportables à minima).

Avancer par petits pas

Dans un contexte de forte incertitude, est-il possible de livrer de petites briques plutôt qu’un gros outil monolithique ? La méthode des petits pas désamorce la peur du mauvais choix.

• Prototypage rapide et limité (un process pour un cas d’usage pour un seul service) ;
• Architecture modulaire (une fois qu’un cas est validé, avancer avec le cas suivant) ;
• Définition de critères de réussites mesurables (avant de commencer).

Les spécialistes logiciels pointeront du doigt les failles de cette approche : le risque du POC permanent, la dette technique importante et le besoin de ré-architecturer plutôt que d’empiler, la multiplication des outils qui entraîne d’autres risques dont personne n’a besoin.

Croissance et durée de vie

Quand on compare les différentes solutions envisagées, les vendeurs ne parlent jamais de la fin de leurs outils, de leur modèle économique et des pivots qu’ils pourraient être contraints de réaliser. Les outils n’ont pas de date de fin. Pourtant, la majorité des nouveaux outils vont s’arrêter, être rachetés ou absorbés d’ici à 18 mois ou à peine plus longtemps.

Pour chaque fournisseur potentiel :

• Quelle est la stratégie exposée du fournisseur ?
• Quelle est la roadmap, le planning des livraisons ?
• À quel stade en sont-ils ? Sont-ils financièrement viables ? solides ?
• Combien ont-ils d’utilisateurs ? de clients ? de contributeurs ? de partenaires ?
• Sont-ils clairs par rapport aux données (RGPD, sécurité) ?
• Comment évoluent les coûts lorsqu’il faut scaler (le coût réel total est un vrai sujet – pricing à l’usage, budgétiser alors qu’on ne connaît pas l’usage à venir).

Pas toujours facile d’avoir accès à ces informations. Deux approches sont alors possibles : travailler avec des acteurs connus, solides et rassurants (mais chers et pas très dynamiques) ou bien préférer les petits nouveaux agiles et souvent moins chers mais pas forcément fiable.

Des recommandations qui expliquent les choix

Parmi les points précédemment cités, fournir une grille d’évaluation. Commenter si besoin et bien préciser le contexte de chaque évaluation. Le contexte du client + l’analyse permettent d’expliquer les choix formulés et de se protéger plus tard lorsque le contexte aura changé.

Bien appuyer sur les points suivants pour avancer de façon sereine :

1. La réversibilité bat la performance, toujours ;
2. La modularité bat l’exhaustivité : 3 briques solides sont toujours meilleures à 30 fonctionnalités approximatives ;
3. L’approche progressive gagne haut la main : Livrer vite, mesurer, ajuster ;
4. La documentation bat l’intuition.

Et pour finir en beauté, 2 questions centrales supplémentaires :

L’humain, on en parle ? Qui va piloter côté client ? Qui va utiliser au quotidien ? La résistance au changement (peu importe les raisons et même avec les meilleures intentions) fait capoter beaucoup de projets… La résistance au changement tue plus de projets que les bugs techniques – à méditer.

Le facteur temps est très important dans la prise de décision. Mais qu’en est-il une fois la solution approuvée et validée en production ? Au bout de combien de temps faut-il la remettre en question ? Se fixer un budget de sortie de 15% et ré-évaluer tous les 12 mois n’est pas une approche courante, mais on vit une époque atypique, non ?

Alors, commençons par accepter l’inconfort : il n’y aura jamais de réponse parfaite. Les outils idéaux aujourd’hui seront peut-être obsolètes dans 18 mois. Et c’est normal.

La majorité des projets qui échouent ne meurent pas d’un mauvais choix d’outil. Ils meurent de paralysie, de sur-spécification, ou d’absence de relais en interne chez le client. La technologie n’est qu’une pièce du puzzle.

Comme il n’est pas possible de garantir l’avenir, il faut ériger des garde-fous : réversibilité, modularité, documentation. Ces principes survivent aux cycles de hype. Ils permettent aux clients d’avancer sans paniquer au prochain pivot technologique.

Et vous, comment faites-vous ?