Avec la méthodologie Solstice Vibe, nous les aidons à transformer ces opérations répétitives en outils adaptés à leurs pratiques. L’accompagnement prend la forme d’un sprint de six semaines : installer la chaîne de montage, choisir les cas d’usage, fabriquer de premiers outils et transmettre la méthode pour poursuivre. Nos interlocuteurs sont des référents désignés dans l’équipe, qui apprennent avec nous à fabriquer et à faire évoluer les outils. Le sprint est en cours au moment où nous écrivons ces lignes.
1. Installer les modules de la chaîne de montage
Pour comprendre cette chaîne de montage, suivons le parcours d’un outil : il faut écrire son code, le conserver, puis le rendre utilisable par l’équipe. Trois modules remplissent ces fonctions.
L’IA de code aide à fabriquer. À partir d’un besoin décrit en français, elle écrit ou modifie le programme. Nous lui fournissons aussi des consignes permanentes, valables pour tous les outils : règles métier, façon de structurer une application, principes de qualité et de traitement des données. C’est l’outil de travail des référents et de nos consultants.
Le dépôt de code conserve le travail. Il rassemble les fichiers du programme et l’historique de leurs modifications. On peut retrouver une version précédente, comprendre une évolution et reprendre le projet à plusieurs. Chez Angie, ce module s’appuie sur le GitLab interne, en lien avec la DSI.
L’hébergement rend l’application accessible. C’est l’endroit où elle fonctionne, pour que ses utilisateurs puissent l’ouvrir depuis une adresse web. Selon les besoins, on y associe une base de données pour conserver des informations. Les comptes, les accès et l’emplacement des données sont définis avec l’entreprise.
Ces modules travaillent ensemble : on fait évoluer le code, on en enregistre une version, puis on met cette version à disposition des utilisateurs. La chaîne de montage, installée une fois, sert à tous les outils suivants.
Angie garde la main sur ses choix de fournisseurs. Chacun des trois modules décrits ci-dessus peut être remplacé par un équivalent. Un changement demande quelques adaptations, mais les règles métier et le travail réalisé sont inscrits dans le code, dont Angie reste propriétaire.
2. Partir des gestes du métier
La chaîne de montage donne les moyens de fabriquer. Reste à choisir ce qui doit l’être.
Nous partons avec les équipes d’une tâche réellement effectuée : quels documents ouvrent-elles ? Quelles informations cherchent-elles ? Que recopient-elles ? Comment savent-elles que le travail est terminé et correct ?
« Automatiser le reporting » devient alors une suite d’opérations concrètes : récupérer les données, harmoniser leurs formats, calculer les indicateurs, remplir le document attendu. Cette description fait aussi apparaître les exceptions et les étapes qui demandent un jugement humain.
Pour choisir les premiers projets, on regarde la fréquence de la tâche, l’effort qu’elle demande, la disponibilité des données et la facilité à vérifier le résultat. Quelques exemples réels (fichiers reçus, documents produits) permettent ensuite de préciser les écrans, les actions et les règles du futur outil.
On choisit aussi le bon format. Une fonction à ajouter dans un logiciel utilisé dans le navigateur peut prendre la forme d’une extension, comme décrit dans notre article sur les extensions Chrome. Un traitement de plusieurs fichiers ou un espace partagé peut devenir une application web.
3. Fabriquer les premiers outils sur des cas concrets
Voici deux des trois outils que nous développons avec les référents d’Angie, à partir des besoins des équipes.
Premier outil : vérifier les articles avant leur diffusion
L’outil est un comparateur. Il confronte le document Word validé, qui sert de version de référence, à l’article tel qu’il a été mis en ligne, et signale les différences, pour repérer une phrase oubliée ou un mot modifié lors de la mise en ligne.
Un premier essai a montré que le blog à vérifier refusait les visites de robots : le site bloque les programmes qui chargent ses pages automatiquement. Nous avons donc choisi le format de l’extension Chrome, présenté dans notre article sur les extensions Chrome. L’extension lit l’article tel qu’il s’affiche dans le navigateur de l’utilisateur, comme pour n’importe quel lecteur, et lance la comparaison depuis cette page.
Pour fabriquer le comparateur, nous précisons les éléments à comparer et la manière d’afficher les écarts. Nous l’essayons ensuite sur plusieurs articles représentatifs : le programme doit retrouver le texte et les titres, sans les confondre avec les menus ou les autres éléments de la page.
L’IA sert ici à écrire le programme. La comparaison elle-même suit des règles programmées, sans appel à un modèle d’IA. Conséquences : le même article donne toujours le même résultat, chaque différence signalée s’explique par une règle, et les textes ne sont transmis à aucun fournisseur d’IA.
Second outil : préparer les reportings social-médias
L’équipe récupère des données de performance sur les réseaux sociaux, les traite, puis les intègre dans des documents de restitution. Nous reprenons ce parcours étape par étape pour définir ce que l’application doit automatiser : quelles données récupérer, comment calculer les indicateurs et où placer les résultats.
Une première version est testée sur un reporting réel. On vérifie les chiffres et le document obtenu, puis on corrige les écarts ou les formats mal pris en charge. L’objectif est de confier au logiciel les manipulations répétitives pour que l’équipe puisse se concentrer sur l’analyse.
4. Corriger, faire évoluer et lancer les outils suivants
Les outils continuent à évoluer une fois en service. Lorsqu’un utilisateur repère une erreur ou demande une évolution, on décrit le cas à l’IA de code, on lui fait modifier le programme, puis on vérifie le résultat.
Avant de mettre la nouvelle version à disposition, on la teste aussi sur les fichiers qui fonctionnaient déjà. On contrôle qui peut accéder à l’application et où elle envoie ou conserve les données. Les exemples de test et les consignes restent avec le code pour pouvoir refaire ces vérifications à la prochaine modification.
À la fin du sprint, les référents de l’équipe apprennent à pratiquer ces étapes avec nous : formuler une demande, tester la réponse, enregistrer une version et la mettre en service. Ils savent ainsi ce que contient chaque outil et comment il évolue. Après le sprint, nous pouvons prendre en charge la maintenance simple (corrections, petites évolutions, adaptation à un changement de format ou de page).
La conception de nouveaux outils peut faire l’objet de nouveaux sprints projets, où nous reprenons le travail de conception avec les équipes.
