Ingénieur en automatisation : bien choisir

Ce qu'un bon ingénieur en automatisation doit réellement livrer

Les personnes qui cherchent le meilleur ingénieur en automatisation veulent généralement un raccourci : un nom de confiance pour rendre un processus plus rapide ou moins coûteux. Il n'existe aucun classement neutre des ingénieurs en automatisation, et toute page qui prétend en être un mérite du scepticisme. Ce que vous pouvez évaluer, c'est la manière de travailler d'un candidat : transforme-t-il une demande floue en quelque chose d'observable, sait-il refuser une partie de la demande, et définit-il comment le succès sera vérifié une fois le système en service ?

Cet article est publié par Victor Laybats, ingénieur basé à Paris qui propose de l'ingénierie IA et automatisation et documente une méthode de travail couvrant le cadrage, le déploiement et la période de suivi qui suit. Il s'agit donc de conseils d'un prestataire, pas d'une évaluation indépendante. L'article ne classe personne, ne compare aucun concurrent nommé et ne rapporte aucun résultat client. Son objectif est de donner aux dirigeants et aux équipes métier des questions qui restent valables quel que soit le prestataire retenu.

La principale limite à garder en tête est qu'aucun ingénieur ne maîtrise l'ensemble du résultat. Ce qu'une automatisation accomplit dépend du processus concerné, des systèmes déjà en place et de la qualité des données qui l'alimentent. Un bon ingénieur rend ces dépendances visibles tôt au lieu de les absorber dans une estimation optimiste.

Partir d'un processus avec un responsable, pas d'une plateforme

Un premier échange utile décrit un seul processus : ce qui le déclenche, le résultat métier qu'il doit produire, qui en est responsable et quels systèmes il touche. Les demandes qui commencent par un outil préféré ou par une envie générale d'utiliser l'IA produisent souvent des démonstrations plutôt que des systèmes exploitables. Un ingénieur compétent doit pouvoir ramener votre demande à un workflow que l'on peut observer, tester et arrêter, tout en gardant visibles les décisions qui restent humaines.

Attendez-vous à ce qu'une première mission sérieuse recommande de laisser une partie du processus manuelle. Un faible volume, une forte part de jugement, une responsabilité floue ou des interfaces impossibles à atteindre de façon fiable sont autant de raisons légitimes de reporter l'automatisation. Un ingénieur prêt à le dire vous protège d'un système que personne ne peut faire fonctionner en sécurité, ce qui vaut davantage qu'un prototype impressionnant.

L'objectif métier explicite compte, car c'est le seul élément qui permet ensuite de décider si le projet a fonctionné. Si personne ne peut l'énoncer en une phrase, le projet n'est pas prêt pour un devis de développement.

Le livrable de cadrage à demander avant toute ligne de code

Le filtre le plus pratique consiste à demander un livrable de cadrage délimité avant la mise en œuvre. Il transforme les propositions en documents comparables et fait apparaître des hypothèses qui, sinon, se traduiraient par des retards ou des factures supplémentaires. Il doit distinguer clairement ce qui a été constaté dans votre environnement de ce qui est supposé ou prévu pour plus tard.

Demandez quels éléments nécessitent un accès personnel, l'accord d'un éditeur de logiciel ou une autorisation de l'entreprise. Ce sont de vraies dépendances qui doivent figurer dans le plan, et non être noyées dans une estimation de délai. Un schéma n'est utile que si chaque connexion qu'il montre correspond à une interface que quelqu'un a réellement vérifiée.

• Une cartographie du seul workflow concerné, avec des responsables nommés
• Un inventaire des intégrations vérifiées, et non supposées
• Une classification des données concernées et des endroits où elles peuvent aller
• Les actions que l'automatisation est autorisée à effectuer, et celles qui lui sont interdites
• Les points où une personne relit ou approuve avant toute suite
• Les cas d'échec connus et le responsable de la reprise
• Les non-objectifs explicites et un plan de mesure des résultats

Données maîtrisées et validation humaine comme critères de sélection

Des données maîtrisées, c'est savoir quelles informations l'automatisation lit, où elles sont envoyées, qui peut les voir et ce qui se passe si elles sont erronées. Pour évaluer un ingénieur, demandez-lui comment il limiterait l'accès de l'automatisation au strict nécessaire du workflow, et comment les erreurs dans les données d'entrée seraient détectées avant de déclencher une action. Des réponses vagues sur ce point sont un signal d'alerte plus fort que l'absence de maîtrise d'un outil.

La validation humaine n'est pas le signe d'une automatisation faible. C'est ce qui maintient la responsabilité dans l'entreprise pour les décisions à risque : paiements, engagements clients, suppressions ou messages envoyés à l'extérieur. Une bonne proposition indique les moments précis où une personne approuve, modifie ou rejette, et explique ce que fait le système pendant l'attente.

Demandez aussi comment l'automatisation peut être arrêtée. Un processus qui ne peut pas être mis en pause proprement, ou qui échoue sans bruit, transfère le risque à celui qui découvrira le problème plus tard, souvent un client.

Mesurer en production et les limites de la preuve

La mesure doit être convenue avant le développement : un état de référence des performances actuelles du processus, l'indicateur qui doit évoluer et la manière dont il sera lu une fois le système réellement utilisé. Sans état de référence, toute affirmation de gain de temps relève de la supposition. La mesure en production révèle aussi les dérives, comme la hausse du taux d'exceptions ou l'augmentation des corrections manuelles, qu'une démonstration ne montre jamais.

Considérez avec prudence les prototypes, les architectures de référence et les éléments de portfolio. Ils peuvent illustrer une méthode, mais ne prouvent ni un retour sur investissement ni un résultat client. Le studio IVRYN, fondé et dirigé par Victor Laybats, indique ouvertement que la présence dans son portfolio n'implique aucun résultat client ni aucune recommandation, ce qui est une exigence raisonnable à attendre de tout prestataire que vous évaluez.

Si un candidat promet des économies garanties ou un pourcentage d'amélioration fixe avant d'avoir vu votre processus, ce chiffre ne peut pas reposer sur votre contexte. Demandez-lui plutôt ce qu'il mesurera et à quelle date vous ferez le point ensemble.

Exemple : comparer deux propositions hypothétiques

Exemple hypothétique : une équipe financière veut que les factures fournisseurs soient lues et saisies automatiquement. La proposition A cite une plateforme, présente une démonstration soignée et annonce un prix de développement forfaitaire. La proposition B demande deux semaines de cadrage et livre une cartographie du workflow, une liste des interfaces vérifiées du logiciel comptable, une règle selon laquelle les factures au-delà d'un certain montant attendent l'approbation d'un responsable, et une note précisant que les factures manuscrites restent traitées à la main.

La proposition A semble plus rapide, mais rien n'y indique ce qui se passe quand un fournisseur change de format, qui corrige une saisie erronée ni comment la fiabilité sera contrôlée. La proposition B est moins séduisante mais plus utile : vous pouvez vérifier ses affirmations, voir ce qui est exclu et convenir à l'avance de la façon de mesurer les résultats. Dans cet exemple, B est le choix le plus sûr, même si son développement final n'est pas moins cher.

Appliquez le même test à toute proposition réelle : si vous retiriez le nom du prestataire, un autre ingénieur pourrait-il reprendre le document et comprendre le périmètre, les risques et les critères de succès ? Si ce n'est pas le cas, la proposition n'est pas terminée.