Gestion Commerciale

Présentation du projet

Le projet Gestion Commerciale, ou GesCo, est une application Web développée par Innlog dans le cadre de sa branche Développement Spécifique. Il s’agit d’un outil de gestion commerciale pensé pour accompagner les entreprises dans le pilotage de leurs activités commerciales, avec une attention particulière portée aux acteurs du secteur viticole.

Parmi ces clients, certains sont des négociants en vins primeurs, un segment aux règles métiers spécifiques, fondées sur des logiques de vente anticipée, d’engagements budgétaires, et de livraisons différées. Les campagnes sont souvent rythmées par des millésimes, des allocations limitées et des objectifs de vente à atteindre, ce qui nécessite une gestion rigoureuse et adaptable.

GesCo se distingue par sa modularité : l’application est conçue pour être personnalisée selon les besoins de chaque client, qu’il s’agisse de suivi budgétaire, de gestion d’offres commerciales, de campagnes primeurs ou de facturation. Cette approche sur mesure permet de répondre aux contraintes variées des utilisateurs, tout en centralisant les données essentielles et en facilitant le suivi des performances commerciales.

Objectifs

L’objectif principal du projet GesCo était de fournir aux clients d’Innlog une solution adaptée aux exigences spécifiques de la gestion commerciale dans le secteur viticole, et plus particulièrement à celles liées à la gestion des campagnes de vin primeur. Cette démarche s’inscrivait dans un besoin clairement identifié : améliorer la traçabilité et la lisibilité des engagements commerciaux au fil des campagnes.

Dans ce cadre, l'une de mes missions a consisté à concevoir un module de suivi budgétaire permettant de comparer, pour chaque campagne, les budgets prévus, les volumes réellement engagés et les résultats des années précédentes. L’outil devait permettre aux utilisateurs de disposer d’une vision consolidée de leurs performances commerciales, facilitant ainsi les analyses et la prise de décision en cours ou en fin de campagne.

L’approche visait également à renforcer la fiabilité des données présentées, en s’appuyant sur des calculs automatisés et des représentations claires des écarts observés. Le module devait s’intégrer de façon fluide dans l’environnement existant, tout en respectant les logiques métier des utilisateurs, souvent familiers d’outils spécialisés dans le vin.

Enjeux de la réalisation

L’un des enjeux majeurs de cette réalisation reposait sur la transformation d’un besoin fonctionnel en un outil visuel pertinent, directement intégré à une interface déjà existante. Il fallait trouver un équilibre entre l’ergonomie attendue par les utilisateurs et les contraintes techniques du socle applicatif Dolibarr.

L’analyse comparative entre les budgets confirmés, prévisionnels et réalisés impliquait une bonne structuration des données en base, une gestion rigoureuse des campagnes commerciales, ainsi qu’une capacité à restituer dynamiquement des écarts chiffrés et des indicateurs visuels.

La réussite du projet dépendait donc autant de la justesse des calculs métiers que de la fluidité de l’affichage et de la pertinence des choix d’interface.

Risques et contraintes

Parmi les contraintes principales, il y avait la nécessité d’intégrer cette nouvelle fonctionnalité dans un environnement existant, sans altérer les modules déjà en place. Cela impliquait de respecter une cohérence d’interface tout en évitant les effets de bord dans la base de données partagée.

Un autre risque concernait la lisibilité des données : si les écarts budgétaires étaient mal interprétés, cela pouvait générer des décisions commerciales inappropriées. Il fallait donc concevoir des affichages robustes, explicites et pédagogiques, en évitant toute ambiguïté dans la restitution des résultats.

Enfin, le projet devait respecter un délai de livraison court, imposant une planification rigoureuse, un bon découpage des tâches, et une coordination fluide entre la phase de maquettage et la réalisation technique.

Ma position dans le projet

Durant ce projet, j’ai intégré le pôle Supply Chain d’Innlog en tant que stagiaire en développement full-stack. À mon arrivée, l’équipe chargée du projet était composée de deux développeurs et d’une cheffe de projet, ce qui portait notre effectif à trois développeurs en tout. Le projet GesCo, initialement porté par l’équipe du Développement Spécifique, avait été transféré, quelques mois avant le début de mon stage, au pôle Supply Chain, dans l’objectif d’en faire un produit plus généralisable et adapté à une commercialisation plus large. Toutefois, plusieurs mois après la fin de mon stage, face à la priorité donnée à d’autres projets stratégiques, le projet a finalement été réintégré dans l’équipe du Développement Spécifique, qui en assure aujourd’hui le maintien et les évolutions auprès des clients existants.

Dans ce contexte, j’ai été amené à travailler sur un projet transversal, à la croisée de deux équipes techniques aux approches complémentaires. Ma mission principale consistait à développer de nouvelles fonctionnalités pour l’application, avec un focus particulier sur le module de suivi budgétaire.

J’intervenais de manière autonome sur l’ensemble du cycle de développement, en assurant à la fois la mise en place des traitements back-end en PHP, l’intégration des données issues de la base MariaDB, ainsi que la conception des interfaces côté front-end. Ce positionnement m’a permis de contribuer à la fois à l’évolution fonctionnelle du projet et à sa stabilité technique.

Mise en œuvre

Information

Avant d’aborder cette réalisation, il est important de souligner qu’elle m’a permis d’approfondir et de mettre en pratique plusieurs compétences techniques et humaines. Certaines d’entre elles sont détaillées dans d’autres sections de ce portfolio. Si certaines explications vous semblent trop succinctes, je vous invite à vous y référer pour une meilleure compréhension.

Première tâche - Maquettage

Le point de départ de cette réalisation a été la co-conception du module Suivi du budget en collaboration avec ma cheffe de projet. Ensemble, nous avons organisé plusieurs sessions de cadrage afin de confronter les attentes métiers à la réalité technique du projet. L’objectif était d’offrir aux utilisateurs une vue claire, lisible de la performance commerciale, en tenant compte des spécificités du secteur des vins primeurs.

Pour mener à bien cette tâche, j’ai utilisé Figma, et intégré le fichier de travail collaboratif déjà utilisé par l’équipe. Celui-ci servait de socle commun, avec une représentation centralisée des composants graphiques, des pages existantes et des logiques d’alignement visuel. Cela m’a permis de créer des maquettes conformes à la charte graphique de l’outil, tout en optimisant la compatibilité avec l’implémentation front-end. Grâce à cette méthode, les maquettes produites reflétaient précisément le rendu final attendu dans l'application.

Analyse du besoin client

Dans un premier temps, j’ai synthétisé les demandes exprimées par le client à partir de son cahier des charges, puis proposé une version optimisée de la maquette. Celle-ci visait à améliorer la lisibilité des comparaisons entre années et à rendre l’affichage plus intuitif.

Sur l’image ci-dessous, la partie supérieure correspond à la proposition brute du client, tandis que la partie inférieure illustre la version enrichie issue de nos échanges internes.

Intégration dans l’environnement applicatif

Dans un second temps, j’ai intégré les éléments validés dans l’interface globale de l’outil. Cette étape visait à vérifier la cohérence graphique, l’encombrement visuel et la compatibilité avec les composants techniques existants.

Le besoin ayant été clairement défini dès le départ, aucun ajustement majeur n’a été nécessaire après validation client. J’ai donc pu procéder directement à la maquettes finale, intégrée à l’écosystème de l’application.

Lecture et interprétation des maquettes

Les maquettes réalisées pour le module « Suivi du budget » présentent deux types d’informations complémentaires, organisées de manière à faciliter la lecture et l’analyse.

Sur la partie gauche de l’interface, deux tableaux sont proposés : le premier regroupe les courtiers – c’est-à-dire les fournisseurs identifiés directement dans les offres de vins primeurs – ; le second recense les négociants, mandatés pour vendre les vins des producteurs. Chaque ligne correspond à une instruction de mise, autrement dit à une offre commerciale liée à un vin précis.

Pour chaque entité, les indicateurs principaux sont affichés : la valeur d’achat cumulée sur l’année en cours (N), ainsi que le volume exprimé en équivalent bouteille de 75cl. À côté de ces données, deux colonnes supplémentaires permettent de comparer ces valeurs avec celles de l’année précédente (N-1), et de visualiser immédiatement les écarts, à la fois en valeur absolue et en pourcentage. L’emploi d’une coloration verte ou rouge selon la direction de l’écart facilite l’interprétation rapide des résultats, qu’il s’agisse d’une amélioration ou d’une baisse.

La partie droite de l’écran propose, quant à elle, une synthèse plus globale sous forme d’encadrés. Un premier bloc présente les données budgétaires : il met en évidence le budget confirmé de l’année N, comparé au budget prévisionnel fixé initialement, ainsi qu’aux résultats réels constatés lors de l’année précédente. Un second bloc suit la même logique, mais en se concentrant cette fois sur les volumes, toujours ramenés à une équivalence bouteille standard. Pour chaque comparaison, sont affichées la valeur obtenue, l’écart absolu et la variation en pourcentage.

Cette organisation visuelle a été pensée pour allier précision analytique et facilité d’usage. Elle permet aux utilisateurs de repérer d’un coup d'œil les écarts majeurs, tout en ayant la possibilité d’entrer dans le détail par acteur commercial, selon leur besoin d’analyse.

Deuxième tâche - Back-end

Le développement back-end du module de suivi budgétaire s’appuie sur une architecture inspirée du modèle MVC, avec une séparation claire entre la logique métier (Modèle), les traitements de flux (Contrôleur) et les composants d’affichage (Vue). Ce développement a été réalisé en PHP, un langage et framework faisant partie des technologies Web, et s’inscrivait dans l’environnement technique imposé par Dolibarr.

J’ai conçu et développé en autonomie à la fois le modèle métier et le contrôleur associé, en respectant les contraintes spécifiques de l’environnement Dolibarr ainsi que les besoins fonctionnels exprimés par l’équipe projet.

Modèle - suivibudget.class.php

La classe Suivibudget est le cœur du module budgétaire. Elle hérite de la classe Core_innlog et encapsule l’ensemble de la logique métier nécessaire au suivi et à la comparaison budgétaire. Elle regroupe des méthodes CRUD, des fonctions de récupération de données spécifiques par typologie de client (courtiers et négociants), ainsi que des méthodes dédiées aux calculs d’écarts entre les années commerciales (année N, N-1, et prévisionnel).

Ces méthodes s’appuient sur des requêtes SQL complexes exécutées sur une base MariaDB, administrée via PHPMyAdmin, pour agréger les données issues des campagnes commerciales. Chaque méthode renvoie des objets structurés avec à la fois les données brutes (valeurs d’achat, volumes) et les indicateurs calculés (écarts en pourcentage et en valeur absolue).

Modèle - Récuperation de lignes de courtiers

public function fetchLinesCourtier($year) {
    $sql = 'SELECT ... WHERE o.year = ' . $year;
    $resql = $this->db->query($sql);
    // Traitement des résultats et calcul des variations
    return $arrCourtier;
}

L’exemple suivant illustre l’une des méthodes du modèle, qui extrait les lignes budgétaires associées aux courtiers pour une campagne donnée.

Contrôleur - component.php

Le contrôleur associé assure la coordination entre la couche métier et la vue. Son rôle est de :

• Instancier la classe Suivibudget avec la connexion à la base ;
• Récupérer dynamiquement l’année sélectionnée par l’utilisateur via GETPOST('year') ;
• Appeler les méthodes du modèle pour collecter l’ensemble des données nécessaires à l’interface ;
• Transmettre ces données à la vue correspondante, via l’inclusion du fichier card.tpl.php.

Contrôleur - Récuperation des données

if ($year > 0) {
    $inn_object->fetch($year);
    $listCourtier = $inn_object->fetchLinesCourtier($year);
    $listNegociant = $inn_object->fetchLinesNegociant($year);
    $listVarBudget = $inn_object->getVariationBudget($year);
    $listVarVolume = $inn_object->getVariationVolume($year);
    include 'tpl/card.tpl.php';
}

Ce fichier fait office de point d’entrée pour la restitution de la donnée budgétaire dans l’interface utilisateur.

Troisième tâche - Front-end

La partie front-end a été conçue pour restituer les indicateurs budgétaires de façon claire, structurée et directement exploitable par les utilisateurs. J’ai développé les différents composants d’interface de manière autonome, en m’appuyant sur les standards ergonomiques existants dans l’environnement Dolibarr.

L’interface se compose de plusieurs blocs distincts, chacun spécialisé dans l’affichage d’un jeu de données métier (variations de budget, variations de volume, listes de résultats par typologie). Ces blocs sont assemblés dynamiquement dans un composant principal, décrit ci-dessous.

Vue - card.tpl.php

Le fichier card.tpl.php agit comme vue maître du module. C’est lui qui orchestre l’affichage global en intégrant les différents sous-composants d’interface. Il définit la structure principale de la page et répartit les éléments dans des zones spécifiques : colonnes latérales pour les indicateurs de variation, zone centrale pour les listes détaillées.

Vue - card.tpl.php

include DOL_DOCUMENT_ROOT.'/custom/'.$module.'/core/modules/'.$element.'/tpl/sub_tpl/variation_budget.tpl.php';
$out_card .= $out;

include DOL_DOCUMENT_ROOT.'/custom/'.$module.'/core/modules/'.$element.'/tpl/sub_tpl/variation_volume.tpl.php';
$out_card .= $out;

include DOL_DOCUMENT_ROOT.'/custom/'.$module.'/core/modules/'.$element.'/tpl/sub_tpl/courtier_list.tpl.php';
$out_card .= $out;

include DOL_DOCUMENT_ROOT.'/custom/'.$module.'/core/modules/'.$element.'/tpl/sub_tpl/negociant_list.tpl.php';
$out_card .= $out;

Chaque sous-vue est incluse dynamiquement, puis son contenu est injecté dans la variable $out_card, qui est ensuite affichée lors du chargement du composant.

Cette organisation permet de maintenir une vue structurée, facile à lire, et compatible avec les évolutions futures tel que l’ajout de filtres complexes ou d’une nouvelle section.

Chaque bloc intégré dans card.tpl.php repose sur une logique de génération HTML dynamique, en s’appuyant sur les données métier préparées en amont par le contrôleur et le modèle.

L’interface s’articule autour de trois zones principales :

• Une zone de synthèse dédiée aux variations de budget, rendue par le composant variation_budget.tpl.php.
• Une zone complémentaire pour l’analyse des volumes confirmés, générée à partir du fichier variation_volume.tpl.php.
• Un tableau détaillé des résultats par courtier, construit avec le composant courtier_list.tpl.php.
• Un second tableau récapitulatif pour les négociants, produit via negociant_list.tpl.php.

Chacun de ces fichiers exploite les données issues du modèle pour générer dynamiquement les tableaux HTML. Un système de mise en forme conditionnelle permet de mettre en évidence visuellement les écarts significatifs :

• En rouge lorsque l’écart est considéré comme préoccupant, soit dépassement de +10 % ;
• En vert pour les écarts favorables, comme la sous-consommation ou la forte progression ;
• En neutre lorsque la donnée est absente ou que la variation est jugée non significative.

Vue - Gestion dynamique des couleurs

if ($info->varAchat > 10) {
    $out .= '<td class="KO-tiers" align="right">'.$info->varAchat.' %</td>';
} elseif ($info->varAchat < -10) {
    $out .= '<td class="OK-tiers" align="right">'.$info->varAchat.' %</td>';
} else {
    $out .= '<td align="right">'.$info->varAchat.' %</td>';
}

Ce bloc applique un style conditionnel aux cellules de tableau selon la variation constatée. Les écarts supérieurs à +10 % sont marqués en rouge (KO-tiers), ceux inférieurs à -10 % en vert (OK-tiers), les autres restent neutres.

Le composant principal, card.tpl.php, orchestré l’assemblage des sous-vues dans une mise en page fluide, qui conserve les repères visuels de l’application existante. Il assure une présentation responsive et centralise l’appel des différents blocs métiers.

Par ailleurs, la récupération des données se fait en amont côté contrôleur, mais un système complémentaire d’appel asynchrone via JavaScript a également été mis en place pour certaines parties de l’application.

JavaScript - Appel API asynchrone

fetch('/api/suivi_budget.php')
  .then(response => response.json())
  .then(data => displayTable(data));

Ce code effectue un appel HTTP vers l’API en JavaScript pour charger les données sans recharger la page. Les résultats sont ensuite transmis à une fonction d'affichage dynamique côté front-end.

Résultat

Le module de suivi budgétaire est aujourd’hui pleinement intégré à l’application commerciale GesCo et est activement utilisé par plusieurs clients du secteur viticole. Son déploiement a permis d’introduire une nouvelle dimension d’analyse dans le pilotage des campagnes commerciales, en offrant aux utilisateurs une vision consolidée de leurs engagements financiers et des volumes confirmés, année après année.

Grâce à une interface claire et structurée, le module facilite la lecture des écarts entre prévisionnel, réalisé et historique, tout en mettant en évidence les points d’attention à travers des indicateurs visuels. Les utilisateurs peuvent ainsi identifier rapidement les écarts significatifs, affiner leurs stratégies de vente et ajuster leurs objectifs en fonction des performances observées.

Dans un environnement aussi spécifique que celui des ventes en vin primeur, où les décisions commerciales doivent souvent être prises rapidement et avec un niveau d’engagement important, cet outil est devenu un véritable levier d’aide à la décision. Sa fiabilité, sa lisibilité et sa capacité à restituer des données complexes de manière intelligible en font aujourd’hui un point d’appui quotidien pour les équipes commerciales.

Avenir du projet

Le module fait aujourd’hui l’objet d’un suivi actif. Un dispositif de maintenance et d’assistance a été mis en place afin de garantir sa stabilité, assurer les corrections nécessaires et accompagner les utilisateurs dans leur utilisation quotidienne. Cette organisation permet de répondre rapidement aux incidents et de maintenir un haut niveau de fiabilité.

Le projet reste évolutif. Des améliorations fonctionnelles peuvent être intégrées à la demande des clients, selon leurs besoins spécifiques. Chaque demande est analysée, puis traitée dans un cycle de développement structuré, incluant spécifications, développement, validation et déploiement.

À court terme, les priorités portent sur l’optimisation des fonctionnalités existantes et la consolidation des usages. Sur le long terme, la solution pourra s’enrichir progressivement, que ce soit par l’ajout de nouveaux indicateurs, des possibilités d’analyse élargies ou une ouverture à d’autres outils métiers selon les orientations fixées par Innlog et ses clients.

Retour sur expérience

Ce projet a marqué une étape importante dans mon parcours. Il s’agissait de ma première véritable expérience en entreprise dans le domaine du développement, et il m’a permis de découvrir le fonctionnement concret d’une équipe technique, les contraintes du monde professionnel et les exigences d’un projet en production. J’ai été plongé dans un contexte réel, avec de vrais utilisateurs, des délais à tenir, des choix techniques à assumer et des résultats attendus.

Ce que je retiens surtout, c’est la progression personnelle que j’ai vécue. J’ai gagné en autonomie, en rigueur, et surtout en confiance. J’ai appris à m’adapter, à chercher des solutions durables, et à livrer un travail exploitable par d’autres. Même si certains aspects techniques ne correspondaient pas forcément à mes préférences, j’ai su composer avec l’existant, faire preuve de pragmatisme, et m’investir pleinement. Voir mes développements utilisés concrètement sur le terrain reste une vraie satisfaction, et m’a donné envie de continuer à évoluer vers des projets plus ambitieux et alignés avec mes appétences.

Compétences liées

Maquettage - Technologie Web - Frameworks - Base de données - Autonomie - Travail en équipe