C1 : Optimiser des applications
Compétence Clé
Simplification de signature de contrat
La figure 1 illustre ma démarche méthodique pour transformer une exigence client en solution technique opérationnelle. À partir de la demande « Simplifier le processus de signature », j’ai structuré une approche rigoureuse en plusieurs étapes. D’abord, l’analyse de l’exigence me permet de la décomposer en spécifications fonctionnelles et non-fonctionnelles. Ces deux types de spécifications convergent ensuite vers une phase de validation cruciale où je développe un POC (Proof Of Concept) pour tester l’intégration API YouSign et valider les contraintes techniques. Cette approche réduit ainsi les risques avant l’implémentation complète et permettre de partager au client une charge de travail approximative. Une fois validé par le client, je procède à l’implémentation progressive de la solution technique : développement de l’interface, intégration API en production, automatisation du workflow complet et déploiement par étapes avec tests utilisateurs. Cette démarche structurée aboutit à des résultats mesurables concrets : transformation d’un processus de 7 étapes manuelles (nécessitant une photocopieuse) en 2 étapes, avec un gain de temps passant de environ 15 minutes à 2 minutes par signature.
Le client m’a exprimé le besoin de « simplifier drastiquement » leur processus de signature de contrats qui était « trop lourd et chronophage ». À partir de cette demande, j’ai dû analyser leurs besoins réels, élaborer des spécifications détaillées et les implémenter techniquement pour transformer leur processus existant.
Savoirs mobilisés
Cette mission a nécessité une compréhension des méthodes d’analyse des besoins client pour transformer des spécification fonctionnelles en spécifications techniques précises. Mes connaissances en analyse fonctionnelle ont été essentielles pour identifier ce que le système doit faire concrètement (fonctionnalités) et comment il doit le faire (performance, ergonomie). Ma compréhension des processus métier m’a permis d’identifier les étapes problématiques dans leur méthode de travail actuelle : téléchargement manuel → signature papier → re-upload → validation email → saisie ERP. Les principes d’intégration d’APIs REST et de services web ont guidé l’élaboration des spécifications techniques pour l’intégration YouSign. Les connaissances en architecture web et en bases de données ont été cruciales pour définir comment intégrer la nouvelle fonctionnalité dans leur système existant qui utilise un ERP. Enfin, la maîtrise des critères de qualité web (temps de chargement, compatibilité mobile, sécurité) a orienté la définition des spécifications de performance.
Savoir-faire mis en œuvre
J’ai d’abord analysé en détail leur processus actuel pour identifier les points de friction : les utilisateurs devaient télécharger le PDF, l’imprimer, le signer à la main, le scanner, le re-télécharger, puis attendre qu’un email soit envoyé au QSHE qui devait ensuite saisir manuellement les données dans l’ERP. À partir de cette analyse, j’ai élaboré les spécifications fonctionnelles concrètes : créer une popup de signature directement dans le navigateur, automatiser l’envoi des emails de notification, et enregistrer automatiquement les données en base sans saisie manuelle. J’ai ensuite défini les spécifications techniques précises : temps de chargement de la popup < 5 secondes, compatibilité mobile et tablette, intégration sécurisée avec l’API YouSign permettant d’intégrer une zone de signature (IFrame) ainsi que la vérification par sms de l’identité du signataire, et mise à jour en base de données du status de signature du contrat ciblé grâce à un webhook envoyé par YouSign lorsque celui-ci reçoit la signature. Pour valider ces spécifications, j’ai développé un prototype rapide permettant de tester l’intégration YouSign et les contraintes de performance avant le développement complet. J’ai implémenté progressivement chaque spécification en commençant par un seul type de contrat, ce qui m’a permis de tester et ajuster la solution avant de l’étendre aux autres types de contrats. Cette approche par étapes m’a permis de vérifier que chaque spécification répondait bien aux besoins initiaux du client.
Utilisation du décorateur pour un système de logging
La figure 2 représente l’impact de l’application des principes SOLID sur l’architecture d’un système. La partie droite révèle une violation flagrante du principe de responsabilité unique (SRP), où un service monolithique concentre toutes les préoccupations : logique métier, logging, gestion du contexte, validation, gestion d’erreurs et formatage des réponses, créant un point de défaillance unique et rendant le système difficile à maintenir et à faire évoluer. La partie gauche démontre une transformation architecturale respectant les principes SOLID : le principe SRP est respecté par la séparation claire des responsabilités (Controller pour les entrées/sorties, Service Métier pour la logique business, Repository pour l’accès aux données), et le principe d’inversion de dépendance (DIP) est illustré par la séparation des préoccupations transversales. Cette refactorisation transforme un système fragile et couplé en une architecture modulaire, testable et extensible, où chaque composant peut évoluer indépendamment tout en maintenant la cohérence globale du système.
Savoirs mobilisés
L’implémentation d’un système de logging transversal a nécessité l’application rigoureuse des principes de conception logicielle. Le principe de responsabilité unique (SRP) a guidé la séparation entre la logique métier existante et les préoccupations de logging, évitant ainsi la pollution du code fonctionnel.
Le pattern Décorateur s’est révélé essentiel pour respecter le principe ouvert/fermé, permettant d’enrichir les fonctionnalités sans modification du code source original. Cette approche préserve la stabilité du système existant tout en ajoutant de nouvelles capacités.
L’application du principe DRY (Don’t Repeat Yourself) a orienté la conception vers une solution centralisée plutôt que la duplication de décorateurs sur chaque méthode. La conception a également intégré les bonnes pratiques de gestion des ressources et d’optimisation des performances, particulièrement importantes dans un contexte de forte charge.
Savoir-faire mis en oeuvre
L’implémentation du pattern Décorateur au niveau classe respecte l’architecture orientée service du framework Adonis tout en évitant la duplication de code. Cette approche démontre l’adaptation des patterns classiques aux contraintes techniques spécifiques.
L’application du principe de robustesse s’est traduite par la gestion des cas où le code décoré n’est pas un service Adonis. J’ai implémenté une pile temporaire avec nettoyage automatique, respectant les bonnes pratiques de gestion mémoire et évitant les fuites de ressources.
La solution finale respecte une architecture en couches claire où chaque composant a une responsabilité définie.
Validation du système de logging par des tests
Cette figure 3 représente le flux de tests complet exécuté lors de la validation unitaire du décorateur de logging. Il illustre l’interaction séquentielle entre la suite de tests, le logger, le décorateur et la méthode d’un service, montrant comment les appels de logging sont interceptés et vérifiés. Cette approche par logger mocké permet de valider de manière isolée et reproductible le comportement du décorateur sans dépendre du système de logging réel.
Savoirs mobilisés
Cette phase de test a mobilisé des connaissances approfondies sur les tests unitaires et les tests d’intégration, ainsi que leur rôle respectif dans la validation de composants. L’approche retenue consiste à tester le décorateur de logging de manière isolée par des tests unitaires, en se concentrant sur ses responsabilités spécifiques sans dépendre d’autres composants du système.
La compréhension des principes de mocking a été essentielle pour isoler le système de logging des dépendances externes. Les mocks remplacent complètement le logger pour créer un environnement de test contrôlé, permettant de se concentrer uniquement sur le comportement du décorateur sans dépendre du fonctionnement du logger réel.
Les concepts d’isolation et de reproductibilité des tests ont guidé la conception des suites de test. Chaque test doit être indépendant et produire le même résultat à chaque exécution.
La maîtrise des assertions et de la validation comportementale a été cruciale pour vérifier non seulement les valeurs de retour mais aussi les interactions entre composants. Les concepts de couverture de code (statement, branch, function coverage) permettent de mesurer la qualité des tests.
Savoir-faire mis en oeuvre
J’ai implémenté une stratégie de test unitaire centrée sur la validation du comportement du décorateur de logging. La configuration des mocks a nécessité une attention particulière pour simuler fidèlement les interfaces du logger tout en permettant l’observation des interactions. J’ai utilisé des mock functions pour capturer les appels et valider que les bonnes informations (méthode, paramètres, contexte) sont transmises au logger.
Le choix de ne pas faire de tests d’intégration sur le logger lui-même est justifié par la complexité technique que cela représente (redirection de sorties, comparaison de fichiers de logs, configuration spécifique du logger (exemple : ne pas afficher l’heure actuel)) et par le fait que le logger est une dépendance externe dont on peut présumer le bon fonctionnement. Cela a donc été évalué comme une perte de temps d’après le développeur en chef du projet, arguments que j’ai aussi validé.