Automatisation sur mesure
Selenium, Cypress et Playwright couvrent le web. Au-delà — client lourd, PowerBuilder, borne de commande, écran de production, terminal métier — la plupart des prestataires s’arrêtent là où l’outil s’arrête. Nous écrivons ce qui manque.
Prendre rendez-vousLe mur
C’est la phrase qu’entendent les DSI dont le cœur du métier ne tourne pas dans un navigateur.
Une application PowerBuilder qui pilote la production depuis vingt ans. Un client lourd Windows dont les champs n’ont pas d’identifiant stable. Une borne dont le navigateur embarqué change de port à chaque redémarrage. Un écran de production qui n’expose aucune interface. Dans tous ces cas, l’outillage standard ne mord pas — et la recette reste manuelle, donc partielle, donc lente.
Ces systèmes ont un point commun : ce sont rarement les moins critiques. Ce sont les applications qu’on n’a pas remplacées parce qu’elles marchent, et qu’on teste à la main parce qu’on croit ne pas avoir le choix.
Ce que nous faisons
PowerBuilder, Windows natif, applications métier sans interface de test.
Pilotage au niveau de ce qui s'affiche, sans rien installer sur la machine du client.
Quand l'interface manque, on va chercher la vérité là où elle est : base, journal, interface applicative, flux d'impression.
La preuve
Nous ne vendons pas une intention : l’atelier a déjà produit un automate complet pour une enseigne de restauration rapide.
Il lit le brief de campagne, écrit la configuration dans le système de caisse, la relit pour vérifier qu’elle correspond, pilote la borne pour contrôler ce que le client voit à l’écran, et compare les points de vente entre eux. 25 704 comparaisons en une minute, là où le même contrôle manuel demandait environ soixante-dix heures.
Ce qu’il a trouvé au premier passage : quatre articles d’une campagne en cours sans aucun prix dans un restaurant, donc invendables, la veille de leur mise en avant. Aucun outil du marché ne savait faire ça — parce que personne ne l’avait écrit.
Comment on s'engage
Livré dans votre dépôt, documenté en français, avec la procédure d'installation et de mise à jour.
Deux à trois semaines pour démontrer que le pilotage tient sur votre système. Si ça ne marche pas, on vous le dit et on s'arrête là.
Sur les équipements exploités, aucun code source, aucun outil de développement : le binaire, ou rien du tout.
Questions franches
Parce qu'il faut d'abord vérifier qu'il couvre votre cas. Quand c'est le cas, nous le disons et nous l'utilisons — c'est moins cher pour vous et plus rapide pour nous. Le développement sur mesure ne se justifie que là où l'outillage standard ne mord pas : client lourd, équipement embarqué, protocole propriétaire, système fermé.
Oui, à condition d'accepter que l'ancrage ne se fasse pas comme sur le web. On s'appuie sur les couches d'accessibilité quand elles existent, sur la reconnaissance visuelle sinon, et on stabilise l'ensemble par des jeux de données maîtrisés. Le premier travail est toujours un essai de faisabilité sur un parcours réel, pas une promesse.
Vous, si vous le souhaitez : le code vous appartient et il est documenté pour ça. Nous, si vous préférez, dans un cadre de maintenance. Ce que nous refusons, c'est la boîte noire que personne d'autre que nous ne peut ouvrir.
Deux à trois semaines pour l'essai de faisabilité, six à dix semaines pour un premier périmètre en service selon la complexité de l'interface et l'accès aux environnements. L'accès est presque toujours le vrai délai, pas le développement.
C'est une question qu'il faut poser avant, pas après. Si un remplacement est prévu à court terme, nous orientons vers une vérification par la donnée plutôt que par l'écran : elle survit au changement d'interface, là où une automatisation d'écran serait à refaire.
Un audit de votre démarche de test, sans engagement, pour savoir où vous en êtes vraiment.
Prendre rendez-vous
French 
English 
Hebrew