Exporter les projets
Exports CSV des projets et des temps passés par employé pour faciliter l’exploitation des données.
Mission 01 · Maintenance évolutive
Gestion Prestation
Maintenir et faire évoluer une application interne conçue initialement pendant mon stage de 2025.
Origine et usage
J’ai initialement conçu Gestion Prestation pendant mon stage de deux mois commencé en février 2025. Au cours de l’alternance, mon rôle n’était donc plus de créer un premier socle, mais d’assurer sa maintenance et ses évolutions au contact de besoins réels.
L’application est complètement déployée en production sur un serveur de l’entreprise. Le pôle Développement Web et le pôle Cybersécurité sont les deux premiers pôles à l’avoir fortement portée et utilisée. Une réunion mensuelle avec le directeur technique permet de suivre son usage, les demandes d’évolution et les perspectives.
Elle est destinée à environ 80 à 100 collaborateurs potentiels, soit approximativement l’ensemble des salariés. Ce chiffre décrit la population concernée, pas un nombre d’utilisateurs actifs mesuré. L’adoption reste inégale : certains pôles plus autonomes conservent plus facilement leurs anciens outils et processus. Le directeur général souhaite néanmoins une généralisation progressive à l’échelle de l’entreprise.
Besoin de l’entreprise
Avant la création de Gestion Prestation, plusieurs équipes suivaient leurs prestations avec des méthodes et des outils différents. Les projets, le temps passé, la charge et les informations utiles au pilotage n’étaient donc pas décrits de manière homogène d’un pôle à l’autre. Cette diversité compliquait la consolidation des données et rendait plus difficile une lecture commune de l’activité.
L’entreprise souhaitait disposer d’un outil unique pour réunir progressivement les projets, les clients, les unités métier, les consultants, le planning, la charge et les éléments de facturation. L’enjeu n’était pas d’imposer immédiatement un fonctionnement identique à toutes les équipes, mais de construire un référentiel commun pouvant accompagner l’adoption de chaque pôle et harmoniser le suivi dans la durée.
Les données centralisées devaient aussi rester exploitables au-delà de l’application. Les exports et les accès dédiés permettent ainsi des traitements internes complémentaires, des analyses dans Power BI ou des rapprochements avec des données issues de Sage. Gestion Prestation sert donc à la fois au suivi quotidien et à la constitution progressive d’une base commune pour le pilotage de l’entreprise. Elle échange également avec Microsoft Teams, Planner et Outlook via Microsoft Graph.
Évolutions réalisées pendant l’alternance
Préparer Power BI
Création d’endpoints API destinés à une future intégration dans Power BI.
Connecter les données Sage
Les endpoints sont utilisés par des informaticiens de l’entreprise lors d’exports provenant de Sage.
Le besoin d’export est un exemple représentatif de cette maintenance. Les données existaient dans l’application, mais leur exploitation demandait encore des manipulations ponctuelles. J’ai d’abord ajouté des exports CSV pour les projets et les temps passés, puis créé des endpoints API en vue d’une utilisation dans Power BI. Après leur mise à disposition, d’autres informaticiens ont pu les utiliser avec des exports provenant de Sage. Les données sont ainsi plus faciles à réemployer sans modifier le fonctionnement quotidien de l’application.
J’ai également fait évoluer le planning, les synchronisations Outlook, les droits par unité métier, l’interface et la gestion des projets au forfait. Certaines corrections ont porté sur la suppression logique des données et sur l’environnement de développement.
Tableau de bord et indicateurs
Le tableau de bord regroupe plusieurs indicateurs utiles au suivi de l’activité et de la charge. Ils donnent aux responsables et aux collaborateurs un accès rapide aux projets en cours, à l’équipe et au planning quotidien.
| Indicateur ou vue | Mode de calcul | Utilité |
|---|---|---|
| Progression des projets | Heures planifiées divisées par les heures vendues, elles-mêmes calculées à partir des jours vendus × 7 heures ; valeur plafonnée à 100 %. | Comparer le temps consommé au volume vendu pour les projets actifs hors facturation au temps. |
| Équipe de BU | Membres actifs de l’unité métier de l’utilisateur. | Accéder rapidement à l’équipe et, pour les administrateurs, à son taux de remplissage. |
| Taux de remplissage | Heures des tâches internes et événements Outlook rapportées à une journée de 7 heures, du lundi au vendredi. | Visualiser la charge planifiée quotidienne d’un collaborateur. |
| Activités du jour | Plannings affectés à l’utilisateur dont la date courante est comprise entre début et fin. | Identifier les tâches et projets prévus pour la journée. |
| Calendrier et événements Outlook | Mois courant, navigation vers le planning et événements récupérés via Microsoft Graph. | Réunir planning interne et agenda externe. |
Deux écrans relient ces calculs à l’usage quotidien. Le tableau de bord synthétise les informations nécessaires au pilotage, tandis que le planning expose la charge à une échelle directement exploitable par les collaborateurs.
Cette interface illustre le passage de données dispersées à une lecture commune de l’activité. Mon travail a porté sur les calculs, les droits et l’évolution de cette synthèse sans interrompre un outil déjà utilisé. La valeur de l’écran ne réside donc pas dans l’accumulation d’indicateurs, mais dans leur capacité à orienter l’utilisateur vers les projets et périodes qui demandent une attention.
Le planning rend visibles les chevauchements, les périodes disponibles et les activités issues de plusieurs sources. Les évolutions réalisées ont dû préserver cette lisibilité tout en intégrant les événements Outlook. Cette contrainte explique le maintien d’un composant de calendrier spécialisé plutôt qu’un tableau construit sur mesure, plus coûteux à rendre interactif et accessible.
Architecture technique
Gestion Prestation utilise Laravel 11.44.0 et PHPUnit 11.5.10. Les vues Blade sont enrichies par JavaScript et construites avec Vite 6.2.5 ; Tailwind CSS 3.4.17, Bootstrap 5.3.5 et FullCalendar 6.1.17 couvrent la mise en forme, les composants existants et la planification. Côté serveur, j’ai séparé les contrôleurs, les modèles, les services applicatifs et les contrôles d’autorisation.
Le maintien de Blade plutôt qu’une réécriture en application monopage limite le coût d’évolution d’un outil déjà en production. En contrepartie, la coexistence de plusieurs bibliothèques d’interface demande une vigilance particulière pour conserver des styles cohérents et éviter un poids frontend inutile.
| Couche | Principaux éléments | Rôle |
|---|---|---|
| Interface | Blade, JavaScript, Vite | Pages projets, planning, clients, charge et paramètres |
| Application | Contrôleurs et services Laravel | Orchestration des cas d’usage et intégrations |
| Accès | Middlewares BU, consultant, superadmin, clé API | Contrôle du périmètre et des actions |
| Externe | Microsoft Graph, Sage via exports | Échanges avec le système d’information |
Diagrammes techniques
Les deux diagrammes suivants résument le fonctionnement de l’application et ses principales briques techniques.
L’application sert de point central entre les utilisateurs internes, le pilotage des projets et les briques Microsoft utilisées pour l’authentification, le calendrier et la collaboration.
Les échanges externes transitent par le backend Laravel, qui centralise la logique métier et les contrôles d’accès. Ce second diagramme complète la vue de contexte sans répéter le détail des composants internes.
Difficultés et recul
Faire évoluer une application utilisée impose de préserver l’existant et de maîtriser les effets de bord. Les intégrations externes ajoutent des problèmes de droits, de jetons, de réseau et de synchronisation. Les réunions mensuelles constituent donc un outil de validation autant fonctionnel que méthodologique.