Chez Synotis, plusieurs processus du quotidien reposaient sur des outils SaaS : la saisie des temps, sa synchronisation avec nos autres outils internes, la génération des factures et la production des rapports d'activité pour nos clients. Ces outils fonctionnaient, mais ils étaient facturés par employé, et leur coût augmentait avec l'équipe.
En parallèle, les capacités des agents de développement IA ont beaucoup progressé ces derniers mois. Nous voulions savoir jusqu'où elles pouvaient aller sur un cas réel, avec de vrais utilisateurs et de vraies contraintes. Nos propres outils internes étaient un bon terrain d'essai : un besoin connu, des utilisateurs disponibles pour donner leur avis, et un impact limité en cas de difficulté.
Ce que nous avons remplacé
Le périmètre couvre la saisie des temps et sa synchronisation avec nos outils internes. Il inclut aussi l'automatisation de deux tâches qui prenaient du temps chaque mois : la génération des factures et celle des rapports d'activité destinés aux clients. Les données saisies une seule fois alimentent désormais l'ensemble de la chaîne.
La méthode : partir des spécifications
Nous avons travaillé en développement piloté par les spécifications. Avant d'écrire du code, chaque fonctionnalité est décrite : ce qu'elle doit faire, les règles métier à respecter, les cas particuliers. L'agent de développement s'appuie ensuite sur ces spécifications pour produire le code, qui est vérifié par des tests automatisés et relu.
Cette approche a deux avantages. Le besoin est formalisé avant d'être développé, ce qui évite de construire des fonctionnalités floues. Et les spécifications servent ensuite de référence pour vérifier que l'application fait bien ce qui était prévu, y compris après des modifications.
Nous avons également posé des garde-fous dès le départ : des tests automatisés exécutés à chaque mise en production, qui la bloquent au moindre échec, un plan de test écrit pour chaque fonctionnalité et déroulé sur un environnement de recette, une revue de sécurité à chaque évolution sensible, un contrôle des accès et une attention particulière portée aux données de facturation. Le code produit par un agent n'échappe pas aux exigences habituelles de qualité et de sécurité.
Prêt pour la production ?
Développer vite ne dispense pas d'exploiter proprement. Trois volets ont fait l'objet d'une attention particulière avant la mise en service.
Le déploiement et l'exploitation
C'est la partie que nous avons le plus éprouvée. Un outil développé avec l'IA reste une application à exploiter : un déploiement reproductible, des mises à jour maîtrisées, des sauvegardes, une supervision avec alertes, et la possibilité de revenir en arrière en cas de problème.
Concrètement, chaque application est construite, testée et déployée par une chaîne d'intégration continue : un test en échec arrête la livraison. Elle part d'abord sur un environnement de recette alimenté par une copie des données de production, puis en production sur décision humaine. Les versions précédentes restent disponibles sur le serveur pour pouvoir y revenir. Les bases sont sauvegardées chaque nuit, chiffrées et copiées hors site, en Suisse. La supervision suit les serveurs et les applications et alerte l'équipe en cas d'anomalie ; une veille automatique signale chaque semaine les mises à jour de sécurité à appliquer.
Les incidents les plus instructifs ne venaient pas du code généré, mais de l'exploitation : des navigateurs qui conservaient en cache une ancienne version de l'interface face à une nouvelle version du serveur, un mot de passe tronqué par un caractère spécial dans la configuration du déploiement, deux déploiements lancés en parallèle dont le plus ancien a écrasé le plus récent. Chacun a été corrigé et a donné lieu à une règle écrite. Ce que nous ferions autrement : mettre en place l'environnement de recette dès le premier jour. Il n'est arrivé qu'après plusieurs semaines de mises en production directes.
Le test d'intrusion
Les accès et les données de facturation justifient de vérifier la sécurité autrement que par les tests habituels. Un test d'intrusion ne remplace pas les garde-fous posés dès le départ : il vérifie qu'ils tiennent face à une personne qui cherche à les contourner.
Nous l'avons mené en interne, en confiant à un agent IA dédié le rôle d'auditeur de sécurité. À chaque évolution qui touche aux droits, aux accès des applications entre elles ou aux données de facturation, il relit le code en cherchant à contourner les contrôles : consulter les données d'un autre client, s'attribuer des droits, injecter des données malveillantes. Les constats sont classés par gravité, corrigés avant la mise en production, et chaque tentative de contournement devient un cas du plan de test. Sur la gestion des tâches partagées, par exemple, l'audit n'a relevé aucun point critique mais quatre points mineurs, dont un qui permettait de modifier les tâches d'un projet auquel on n'était pas rattaché. Tous ont été corrigés avant la mise en service. L'étape suivante est un test d'intrusion mené par un tiers, que l'audit interne ne remplace pas.
La charge et la performance
Un outil interne n'a pas les volumes d'un site public, mais certains moments sont critiques : la clôture du mois, la génération des factures, la production des rapports pour les clients. Un test de charge permet de dimensionner l'application et de repérer les points faibles avant que les utilisateurs ne les rencontrent.
Nous avons simulé des parcours réels (consultation du planning, saisie des temps) avec une montée progressive jusqu'à 200 utilisateurs simultanés. L'application traite environ 32 requêtes par seconde sur un seul processus, sans aucune erreur jusqu'à 200 utilisateurs simultanés : le temps de réponse augmente, mais rien ne casse. Cinquante consultants travaillant à un rythme réel n'utilisent qu'environ 28 % de cette capacité, avec 95 % des réponses en moins de 0,6 seconde. La saisie en masse a tenu 25 enregistrements par seconde sans erreur. Les données de test ont ensuite été supprimées.
Le test n'a pas tout vu. En usage réel, un écran interrogeait le serveur une fois par projet et saturait l'accès à la base de données. Il ne fait plus qu'un seul appel. Une marge reste disponible : répartir l'application sur plusieurs processus permettrait de tripler sa capacité si l'équipe grandit.
La mise en service
Après deux mois d'utilisation, les anciens outils ont été déconnectés. Nous gardons toutefois une solution de repli jusqu'à la fin de l'année, le temps de couvrir un cycle complet de facturation et de clôture avec les nouvelles applications.