Stage de 2ème année
Licence Pro MIAW
Présentation du sujet et structure d'accueil
Ce stage de deuxième année de Licence Professionnelle Métiers de l'Informatique – Applications Web se déroule au sein de THF-ES, bureau d'étude spécialisé dans le secteur des télécommunications, situé à Provins (77160). L'entreprise intervient sur la sécurité et la supervision de travaux menés sur des installations télécom : pylônes, toits techniques, antennes relais et autres infrastructures du réseau. Parmi ses clients figurent des acteurs majeurs de l'infrastructure télécom française tels qu'ONTOWER, CELLNEX ou encore DELTA ZONING, ce qui confère à l'entreprise un volume d'interventions élevé et une grande diversité de missions terrain.
THF-ES compte une quarantaine de collaborateurs, dont plus de la moitié sont des techniciens itinérants amenés à se déplacer quotidiennement sur le terrain à travers tout le territoire. Cette réalité opérationnelle est au cœur du projet qui m'a été confié. Je travaille en étroite collaboration avec mon tuteur de stage, Quentin Foessel, ainsi qu'un autre développeur impliqué sur le projet, sous l'impulsion du directeur général, à l'initiative de cette démarche de digitalisation interne.
Le projet consiste en le développement from scratch d'une application web nommée THF Operations Telecom Project, dédiée aux employés itinérants. L'outil leur permet de remplir des formulaires structurés directement depuis le terrain, via leur smartphone, de manière rapide et intuitive. Les données saisies sont stockées en base et consultables sous format PDF par les employés de bureau disposant des droits d'accès nécessaires — offrant ainsi une traçabilité complète de chaque intervention.
Analyse du besoin
Existant et ses limites
Avant ce projet, les employés de THF-ES s'appuyaient sur deux solutions pour gérer leurs comptes-rendus terrain. La première consistait à rédiger des rapports sous Microsoft Word, puis à les transmettre par e-mail aux équipes de bureau. Cette méthode s'est révélée longue, fastidieuse et propice à la désorganisation : les pièces jointes s'accumulent dans les boîtes mail, les versions se multiplient, et il devient difficile de retrouver un document précis parmi des centaines d'échanges. Le risque de perte d'information ou d'oubli de transmission est réel, et le traitement côté bureau implique une ressaisie manuelle chronophage.
La seconde solution était Kizeo Forms, un outil SaaS spécialisé dans la saisie de formulaires sur mobile. Kizeo répondait mieux aux contraintes terrain, mais présentait deux obstacles majeurs. D'une part, son modèle tarifaire repose sur un abonnement par utilisateur, ce qui représente un coût récurrent et croissant à mesure que l'effectif itinérant augmente. D'autre part, l'entreprise se retrouvait dans une dépendance totale vis-à-vis d'un prestataire externe : en cas d'évolution tarifaire, d'interruption de service ou de changement de politique, THF-ES ne dispose d'aucun levier. Cette absence de maîtrise sur un outil aussi central à l'activité opérationnelle est perçue comme un risque stratégique inacceptable à moyen terme.
Objectifs et périmètre fonctionnel
L'objectif est de concevoir une solution sur mesure, hébergée et maîtrisée en interne, sans abonnement récurrent, et parfaitement adaptée aux usages réels des équipes. La volumétrie existante dans Kizeo donne une idée de l'intensité d'utilisation à couvrir : à titre d'exemple, le formulaire Rapport Accès comptabilise à lui seul plus de 3 200 entrées, Reprogrammation BAC dépasse 2 300 soumissions, et Travaux CELLNEX en recense plus de 1 500. Au total, 15 types de formulaires distincts sont identifiés, couvrant des interventions aussi variées que les audits sécurité, les travaux sur pylônes, les visites techniques, les déconsignations ou encore les campagnes ILOQ.
Pour répondre à ces besoins, l'application doit permettre la sélection du type de rapport adapté à l'intervention, la saisie de champs structurés (texte libre, listes à choix multiples, cases à cocher, dates) ainsi que la capture et l'attachement de photos. À titre d'exemple, le formulaire d'audit sécurité comprend plusieurs sections : informations sur le site (code, adresse, nature de l'édifice, information FAS), conditions d'accès (boîte à clefs, type de BAC, points bloquants, photos des clefs), informations générales (état de la terrasse, accès aux éléments de fixation des aériens, éligibilité au PPMS), reportage photo des anomalies, inventaire des éléments constitutifs, et compléments (intervenant, remarques libres, galerie photo). Cette richesse structurelle illustre la complexité de digitalisation que représente le remplacement de Kizeo.
Une attention particulière est portée à l'expérience mobile : les itinérants étant les utilisateurs principaux, l'application est conçue selon une approche mobile-first, avec une exportation prévue sous forme de Progressive Web App (PWA) afin d'être installable sur les terminaux des techniciens sans passer par les stores d'applications.
Missions confiées et planification
Réalisations des trois premières semaines
Le développement de l'application a débuté par la conception de l'architecture back-end en PHP / Symfony, selon le patron MVC. L'interface utilisateur a été intégralement mise en page selon un thème sombre professionnel, cohérent avec l'identité visuelle de l'entreprise, et entièrement responsive. Le tableau de bord principal présente en un coup d'œil la date du jour, un accès rapide à la création d'un nouveau rapport, la liste des interventions récentes, des statistiques globales (total de rapports créés, volume du mois en cours) et l'accès au référentiel de sites.
Un module complet de gestion des rapports est pleinement opérationnel : création, consultation, modification et suppression. Lors de la saisie, le technicien peut joindre des photos depuis sa galerie ou déclencher directement l'appareil photo de son terminal via l'API capture du navigateur. Chaque rapport est identifié par un numéro séquentiel, un titre, un code chantier et un compte-rendu libre. L'export en PDF est fonctionnel grâce à la bibliothèque Dompdf, avec intégration automatique du logo de l'entreprise, de la date et de l'heure d'intervention.
Une base de données de 41 000 sites télécom a été constituée à partir d'un fichier Excel préexistant, maintenu par l'entreprise avant mon arrivée. Chaque site est référencé par un code standardisé (ex. : FR-01-000364), son nom, son adresse, sa ville et son type d'installation (terrain, bâtiment industriel, immeuble résidentiel, etc.). La base est accessible via une page de recherche paginée (1 665 pages), permettant de filtrer par code, nom ou ville. Ce référentiel est aussi directement interrogeable via le chatbot.
Un assistant conversationnel a été intégré et est fonctionnel. Alimenté par l'API Mistral AI, il permet aux techniciens de retrouver un site ou sa référence par simple question en langage naturel, d'obtenir la météo en temps réel sur un lieu d'intervention, ou d'accéder à d'autres informations utiles. Le chatbot est accessible depuis un bouton flottant présent sur toutes les pages de l'application.
Compatibilité mobile
L'ensemble de l'application a été développé selon une approche mobile-first, les techniciens itinérants étant les utilisateurs principaux. Les tests sont menés en continu sur terminal réel via ngrok. Les captures ci-dessous illustrent le rendu sur smartphone — mode sombre et mode clair — ainsi que les vues formulaire et recherche de site.
Méthode de travail et organisation
La planification du projet est gérée de façon agile et collaborative, sans outil formel de ticketing : les tâches sont priorisées à l'oral et par post-its entre les membres de l'équipe de développement. Cette souplesse est adaptée à la taille réduite de l'équipe et à la nature évolutive du projet, où les besoins peuvent être ajustés rapidement. Les échanges à distance transitent par Microsoft Teams pour les informations peu pratiques à communiquer oralement, et le code est centralisé sur un dépôt GitHub partagé, garantissant la traçabilité des développements et la collaboration entre développeurs.
Un axe fort de la méthode de travail est le contact régulier avec les employés terrain. Ces derniers sont consultés tout au long du développement pour valider la pertinence des fonctionnalités, suggérer des améliorations et signaler des contraintes pratiques invisibles depuis le bureau. Leur connaissance du terrain — conditions d'accès difficiles, couverture réseau variable, nécessité d'aller vite — oriente directement les choix d'interface et les priorités de développement.
Travaux restants
Les prochaines étapes prioritaires sont l'intégration de l'ensemble des 15 formulaires métier identifiés dans Kizeo, le remplacement du formulaire générique actuel par les vrais formulaires structurés de l'entreprise (avec leurs sections, types de champs et logiques conditionnelles), et la mise en place d'un système d'authentification avec gestion des rôles (technicien itinérant / employé bureau). La sécurité applicative — protection contre les injections SQL, les failles XSS, la gestion des sessions — est traitée au fil du développement et fera l'objet d'une révision approfondie avant la mise en production. L'export de l'application sous forme de PWA installable sur mobile constitue également une étape clé de la fin du stage.
Veille technologique
Choix du framework back-end — Symfony
Plusieurs frameworks PHP ont été examinés avant de s'engager sur Symfony. Laravel, son principal concurrent, offre une syntaxe plus expressive et une prise en main plus rapide, ce qui en fait souvent le choix privilégié pour des projets de taille intermédiaire. Cependant, Symfony a été retenu pour sa structure MVC rigoureuse, son système de composants modulaires (Doctrine pour l'ORM, Security pour l'authentification, Form pour la génération de formulaires dynamiques) et sa robustesse éprouvée sur des projets amenés à évoluer dans le temps. Sa philosophie de composants réutilisables et son contrat de stabilité à long terme (LTS) en font un choix plus fiable pour une application destinée à être maintenue en interne sans dépendance externe.
Génération de PDF — Dompdf
Trois solutions ont été étudiées pour la génération des rapports PDF. FPDF est une bibliothèque légère mais impose une construction programmatique du document pixel par pixel (positionnement de blocs, gestion des polices à la main), ce qui la rend peu adaptée à des rapports à mise en page complexe incluant des photos et des tableaux de données. wkhtmltopdf est plus puissant et génère des PDFs à partir de HTML/CSS comme un navigateur headless, mais nécessite l'installation d'un binaire système — une contrainte incompatible avec certains environnements d'hébergement partagé. Dompdf a été retenu pour son intégration native en PHP via Composer, son support du HTML5 et du CSS3, et sa capacité à inclure des images encodées en base64 — ce qui facilite l'intégration des photos de chantier et du logo de l'entreprise directement dans le rendu final.
Assistant conversationnel — Mistral AI
Pour l'intégration du chatbot, plusieurs solutions ont été comparées. OpenAI (GPT-4) est la référence du marché, avec des capacités de compréhension du langage particulièrement avancées, mais ses serveurs sont hébergés aux États-Unis, ce qui soulève des questions de conformité RGPD pour une entreprise française traitant des données opérationnelles. Dialogflow (Google) est une solution robuste pour la création d'agents conversationnels structurés, mais sa configuration repose sur la définition d'intents et d'entités, ce qui la rend moins flexible pour des questions en langage naturel libre. Mistral AI, société française fondée en 2023, a été retenu pour plusieurs raisons : ses modèles sont entraînés avec une forte composante francophone, les données sont hébergées en Europe, et son API est simple à intégrer. Pour un usage professionnel en contexte français, Mistral offre un rapport performance / conformité particulièrement pertinent.
Approche mobile — Progressive Web App
La question du déploiement mobile a fait l'objet d'une réflexion approfondie. Développer une application native Android ou iOS aurait impliqué un double développement (ou l'usage d'un framework hybride comme React Native ou Flutter), un processus de validation sur les stores d'applications, et une maintenance distincte de la version web. La Progressive Web App (PWA) permet d'éviter ces contraintes : installable directement depuis le navigateur, elle donne accès aux fonctionnalités natives du terminal (appareil photo, géolocalisation, notifications) via les API web standardisées, tout en reposant sur une seule base de code. Les tests de compatibilité mobile sont réalisés en cours de développement via ngrok, un outil qui expose le serveur local sur une URL HTTPS publique accessible depuis n'importe quel terminal connecté, permettant de tester en conditions réelles sans déploiement.
Recommandations pour la suite du projet
Plusieurs axes d'amélioration sont identifiés pour la phase finale du stage. Sur le plan de la sécurité, la mise en place d'un système d'authentification robuste (hachage bcrypt des mots de passe, protection CSRF sur les formulaires, gestion sécurisée des sessions Symfony) est une priorité avant toute mise en production. Sur le plan de l'expérience mobile, l'implémentation d'un service worker permettrait une mise en cache des formulaires et des données essentielles, offrant un usage partiel hors connexion — une contrainte réelle pour des interventions sur des pylônes en zone rurale à faible couverture réseau. Enfin, la mise en place d'une gestion fine des droits d'accès par rôle (technicien terrain, responsable bureau, administrateur) permettra de sécuriser la consultation des rapports et de l'adapter aux différents profils d'utilisateurs de l'entreprise.