Aujourd'hui, l'informatique assiste de plus en plus les domaines industriels. Cette aide permet de limiter les erreurs humaines dans la fabrication de produits demandant de la précision. Ces erreurs peuvent engendrer des coûts supplémentaires importants pour les entreprises. Certaines intègrent déjà des logiciels informatiques dans leurs processus de fabrication afin d'être assistées dans leurs domaines de productions. D'autres tentent peu à peu d'adopter cette pratique. C'est le cas de la Tonnellerie Saint-Martin, acteur principal de notre projet, spécialisé dans la fabrication de tonneau et de foudre.
Pour accomplir ce projet, nous étions une équipe de 7 personnes constituée d'un Scrum Master et de moi-même en tant que concepteur et développeur. Nous avons fonctionné en méthodologie Agile.
Notre mission était de proposer un outil permettant de réaliser des calculs en prenant des valeurs d'entrées afin d'en sortir toutes les dimensions nécessaires pour la fabrication d'un foudre – barriques de très grande capacité, équivalent à plusieurs tonneaux permettant le stockage des alcools –. On distingue 3 grands types de foudre, la cuve, le rond tel un tonneau et puis l'ovale plus difficile à fabriquer. La fabrication de ces foudres se fait par un foudrier.
Aujourd'hui, des machines existent pour aider à la fabrication des foudres mais elles sont généralement très onéreuses et ne sont pas en toute circonstance adaptées aux demandes. Certaines commandes venant des clients sont très spécifiques. C'est pour cela que l'industrie du foudre est un métier avant tout très manuel contrairement à celui de la simple barrique qui est automatisé.
Mes objectifs ont été les suivants :
Gestion de projet
Développement
L'enjeu était de proposer un outil prenant en entrée la largeur et la hauteur de tête et de bouge – au total 4 valeurs – pour que l'outil puisse calculer en sortie les dimensions et courbures de chaque douelles – planches courbées tenues par un cerclage en fer –. L'interface devait être simple d'utilisation et proposer des calculs sans marge d'erreur afin d'assister les foudriers dans leur travail.
Pour pouvoir réaliser cet outil, il était primordial de trouver les formules adéquates, Là était notre principal risque, de mauvais résultats pouvaient induire en erreur les foudriers.
Les tâches ont été découpées de la façon suivante :
Le travail sur les équations consistait à rechercher des formules selon la méthodologie manuelle utilisée par les foudriers. Cette méthode consistait à tracer à même le sol les dimensions réelles d'un foudre puis de prendre les mesures, méthode fastidieuse. L'équipe qui s'occupait des calculs a appliqué ce principe pour rechercher les équations et en conclure les formules mathématiques.
La deuxième équipe était chargée de développer une première version sous forme de console. Cette version permettait de poser le moteur interne - de l'outil – modèle, logique du programme – puis d'y intégrer les calculs une fois ces derniers trouvés.
Nous avons longuement échangé sur l'architecture technique. Etant donnée la technologie imposée par l'école, à savoir WPF, nous avons décidé de partir sur le MVVC (Model, View et ViewModel) qui est une variation du MVC (Model, View et Controller). A l'instar du MVC, le MVVC vise à séparer le code concernant l'interface du code logique de l'application. Cependant, la différence se trouve dans le ViewModel. Contrairement au Controller, le ViewModel sert de lien bidirectionnel entre l'interface, on appelle ceci le Data Binding. La donnée est modifiée dans le ViewModel et la View s'adapte au résultat. Cette architecture était un choix judicieux pour la technologie imposée.
Une brève définition des différents mots anglais ci-dessous :
A savoir, notre client ne souhaitait pas de base de données hébergée en ligne.
Lors du développement, nous mettions à jour la documentation technique et faisions des reviews – audit interne – régulières de cette dernière pour contrôler la cohérence de l'application avec la documentation. Une fois l'application terminée, une documentation utilisateur était rédigée. Ce document permettait d'expliquer le fonctionnement de l'outil à l'utilisateur.
Durant la durée du projet, nous travaillions avec Git un outil de versioning. Pour chaque feature – fonctionnalité – une branche était déployée. Tant que la fonctionnalité n'était pas validée, nous travaillions sur cette branche à part pour ne pas détériorer la branche principale. Une fois cette feature vérifiée nous faisions un merge – une fusion avec la branche principale de l'outil – ce qui avait pour effet d'ajouter la nouvelle fonctionnalité à l'application.
Nous échangions souvent avec notre client, fonctionnant en méthodologie agile. Durant la première phase du projet, nous avons fourni les calculs au client pour des tests en temps réel. Il s'est avéré que les calculs de l'outil étaient encore plus précis que ceux pris manuellement. Une fois cette partie validée nous pouvions commencer à implémenter les interfaces.
Sur la partie développement de l'outil, j'avais en charge :
Cette partie était destinée à développer une interface type console. Ce menu était pour le moins élémentaire. Il devait récupérer une des 3 valeurs d'entrées associée au type de foudre que l'utilisateur souhaitait calculer puis renseigner successivement les 4 valeurs d'entrées : la largeur et hauteur de tête puis la largeur et hauteur de bouge. La console devait intégrer des vérifications de saisie, c'est-à-dire que tant que l'utilisateur ne rentrait pas des valeurs qui respectaient les conditions, le programme demandait de nouveau la saisie.
J'ai participé au développement des différentes interfaces, la logique étant déjà définie, nous devions binder – ou lier – les champs et valeurs affichées des Views aux ViewModels. Ces interfaces étaient développées avec du XAML.
Il m'est arrivé >d'apporter mon aide lorsqu'une difficulté était rencontrée par un membre de mon équipe et vice-versa. Nous engagions alors une méthodologie qui se nomme le Pair Programming, technique qui consiste à travailler par deux sur un même ordinateur pour être plus performant sur le développement et les tests.
Il existe des dimensions standards des foudres que les entreprises peuvent commander. Mon objectif était d'intégrer dans l'application la capacité de pouvoir sélectionner un standard prédéfini et de pré remplir les champs d'entrées. Le client ne voulant pas de base de données, j'ai intégré un lecteur XML pour sa facilité de lecture.
Ce fichier XML au lancement de l'application est généré automatiquement. Le répertoire « Documents » – chemin simple d'accès – m'a semblé être un bon choix car le langage C# intègre une bibliothèque permettant de récupérer de manière générique et sur n'importe quelle machine, le chemin de ce répertoire.
Ce registre XML intègre la totalité des standards et l'application lit le fichier pour récupérer les dimensions. Le foudrier peut par la suite, à l'aide d'une liste déroulante, sélectionner le standard qui lui convient.
Enfin, ce registre sous format texte peut être édité très simplement par les foudriers pour y ajouter d'autres standards. Ce fichier peut être ensuite copié sur un autre ordinateur qui tiendra compte des nouvelles valeurs.
Ce projet m'a permis de découvrir le métier de foudrier, Nous avons eu la chance d'être accueilli sur le site de production pour une présentation de l'entreprise et des métiers en lien avec la fabrication de foudres et de tonneaux.
J'ai pu approfondir mon sens du service en aidant les membres de mon équipe sur une tâche spécifique. Ceci m'a permis de mieux appréhender les différentes réactions émotionnelles face à une problématique rencontrée. J'ai progressé sur l'utilisation de Git et fait mûrir mes connaissances sur la méthodologie agile.
L'entreprise a été très satisfaite de l'outil permettant un gain de temps conséquent sur la réalisation de leurs foudres. Aujourd'hui, l'application est toujours utilisée pour la production de foudres, aucune demande spécifique – amélioration/ajout – n'a été formulée par la Tonnellerie Saint-Martin.
Mon regard critique : J'étais souvent à l'écoute des besoins de l'équipe. J'ai participé activement à la conception de l'application en proposant mes points de vue sur la bonne concordance de l'architecture logicielle ainsi que sur le développement de certaines fonctionnalités par mes co-équipiers. Nous avions une bonne cohésion d'équipe.
Néanmoins, le projet aurait pu être développé avec une technologie plus récente. En effet, WPF n'est plus autant populaire.