Ce qu’un ingénieur déployé en amont fait et quand vous en avez besoin

Un ingénieur déployé en première ligne est un ingénieur logiciel qui travaille au sein des processus du client plutôt que derrière une pile de tâches en attente. Il collabore avec les personnes qui utiliseront l’outil, découvre comment le travail est réellement effectué, développe la première version à partir de données réelles, et reste jusqu’à ce que l’outil fonctionne dans les opérations quotidiennes. Ce terme provient des entreprises qui vendent des logiciels complexes à de grandes organisations, où un produit ne fonctionne que lorsque quelqu’un l’a intégré aux systèmes et aux habitudes du client.

Cette même méthode de travail convient également aux petites et moyennes entreprises, voire encore mieux. Une petite entreprise dispose rarement d’une équipe informatique interne capable de transformer une idée vague (« L’IA peut-elle lire nos certificats de fournisseur ? ») en spécifications précises. Elle a besoin de quelqu’un qui puisse mener l’analyse, écrire le code et assumer les résultats.

Quelles sont les tâches réelles de ce poste

La majeure partie du travail a lieu avant et après l’écriture du code. Une mission typique passe par quatre phases :

• Découverte. Entretiens avec les personnes qui effectuent le travail, une analyse des documents, tableurs et systèmes réels, ainsi qu’une description écrite du processus actuel y compris ses exceptions. Les exceptions sont particulièrement importantes, car c’est là que l’automatisation échoue.
• Prototype. Un outil fonctionnel utilisant des données réelles en quelques jours, et non un simple diaporama. Il est rudimentaire, mais les utilisateurs peuvent l’essayer et indiquer ce qui ne fonctionne pas.
• Production. Contrôle d’accès, gestion des erreurs, enregistrement des activités, surveillance, sauvegardes, une étape d’approbation pour les résultats incertains, ainsi qu’un ensemble de tests permettant de vérifier si l’outil continue de fonctionner après chaque modification.

Transfert et support. Documentation, une brève formation pour l’équipe, ainsi qu’une méthode convenue pour signaler les problèmes et demander des modifications.

En quoi cela diffère d’un projet classique

Dans un projet à périmètre fixe, le client établit les exigences, le fournisseur les met en œuvre, et les deux parties se disputent sur leur interprétation. Cette approche fonctionne lorsque le problème est bien compris, comme pour un nouveau site web ou une intégration connue.

L’automatisation par l’IA est rarement bien comprise au départ. Personne ne sait combien de factures ont un format inhabituel, avec quelle fréquence un fournisseur envoie une version numérisée au lieu d’un PDF, ou quelle règle l’expert-comptable applique sans l’avoir notée. Un ingénieur déployé sur le terrain découvre ces éléments en travaillant directement avec les documents, de sorte que le périmètre du projet est défini sur la base de faits concrets plutôt que de suppositions.

Cela diffère également du renfort de personnel. Un développeur en renfort reçoit les tâches du chef d’équipe. Un ingénieur déployé en amont est censé décider de ce qui doit être développé, s’opposer lorsque une idée ne donne pas de résultats, et évaluer si le résultat fonctionne.

Lorsqu’une petite entreprise en a besoin

Ce modèle est pertinent lorsque plusieurs de ces conditions sont remplies :

• un processus répétitif consomme des heures chaque semaine : lecture de documents, copie de données entre systèmes, vérification des délais, réponse aux mêmes questions ;
• les données se trouvent en de nombreux endroits : ERP ou 1C, fichiers Excel, pièces jointes d’e-mails, dossiers partagés, documents scannés ;
• quelqu’un a déjà essayé un chatbot ou un prototype de ChatGPT qui fonctionne en démonstration mais pas dans des cas réels ;
• il n’y a pas de développeur interne connaissant à la fois le domaine d’activité et la technologie.

Cela devient moins logique lorsque le processus change chaque mois, lorsqu’il n’y a personne de votre côté pour consacrer quelques heures par semaine à répondre aux questions, ou lorsque des outils prêts à l’emploi peuvent déjà accomplir le travail. Dans ce cas, achetez l’outil.

À quoi s’attendre pendant les deux premières semaines

Nous commençons nos interventions par une période fixe de deux semaines. À leur fin, vous devriez disposer de trois éléments : une carte écrite du processus avec les exceptions identifiées dans les données réelles, un prototype fonctionnant sur un échantillon de vos documents ou dossiers, ainsi qu’une estimation honnête du temps nécessaire pour la mise en production, y compris les tâches qui ne doivent absolument pas être automatisées.

Ensuite, vous décidez si vous souhaitez poursuivre. Une intervention complète dure généralement de deux à six semaines, en fonction du nombre de systèmes impliqués et du degré de révision requis pour les résultats.

Questions à poser avant de recruter quelqu’un

• Le ingénieur travaillera-t-il avec nos données réelles dès la première semaine, et comment le accès est-il contrôlé ?
• Comment saurons-nous que l’outil est correct ? Demandez un ensemble de test et des métriques, pas de promesses. Nos notes sur les évaluations et la révision humaine décrivent à quoi cela ressemble.
• Où les modèles sont-ils exécutés, et nos données quittent-elles notre infrastructure ? Pour les fichiers confidentiels, consultez l’IA locale pour les documents confidentiels.
• Que se passe-t-il après le transfert : qui corrige les problèmes lorsque un fournisseur modifie le format de sa facture ?

Si les réponses sont vagues, le projet le sera également. Si vous souhaitez discuter d’un processus concret, notre page forward-deployed engineering explique comment nous menons ces projets, et vous pouvez nous répondre via le formulaire de contact.