| 29/09/2025 - 08:27 - Monday |
false |
Réorganisation de la semaine |
J'ai réorganisé toute la semaine du 29/09 pour y placer tous les 1-2-1 qui avaient été annulés dans la semaine du
15/09 suite à urgence DSE.
J'ai aussi repoussé au 08/10 la réunion Cycle Planning initialement prévue ce mercredi
01/10 ce qui permettra d'inclure les inputs de la synchro PFE planifiée le 02/10 dans le Cycle Planning du 08/10.
J'ai
inclus Alexis Lefebvre dans la réunion de budget qui avait été planifiée avec Eduard. De la sorte, je fais d'une
pierre deux coups en (1) tenant ma réunion déjà prévue avec EdCr et (2) j'inclus Alexis qui avait pourtant refusé
ce meeting initialement.
J'ai réservé la matinée de demain 30/09 à la mise à jour des fiches Projet PFE et SAE.
J'ai aussi réserver un slot de finalisation des fiches projet le vendredi 03/10 (après synchro PFE du 02/10). Dans la
foulée, j'ai transféré à EdCr et AlLe le meeting d'explication du budget d'Isabelle Roks de mercredi 01/10. Ainsi,
les deux Chefs de Service savent comment lire les fichiers de budget. Le fichier de budget transmis par Isabelle le
24/09 a été transféré pour info (FYI) à EdCr et AlLe.
Déplacement ce lundi 29/09 de l'équipe PFE à
Robermont.
Préparation du meeting des décommissionnements CCS et Géolog (mais aussi sujets GDS et G4S) pour le mardi
30/09.
Passage en revue du 2ème meeting de cadastre prévu le 30/09 à 15:00.
Réservation de temps pour CoPil du
09/10 (les 01/10, 02/10 et 03/10)
|
| 27/09/2025 - 11:00 - Saturday |
true |
Élaboration de budget |
L'obligation de mettre au point le budget d'un département (DSE) qui accueille principalement deux projets (PFE et SAE)
revient au responsable officiel du département. Toutefois, l'élaboration du bduget départemental est un processus
collectif : chaque responsable de centre ou de projet (ici, PFE et SAE) participe activement à la préparation,
fournit ses prévisions de besoins, et valide les estimations propres à son périmètre.
Lors de la crise PFE
(Production PFE V2), Christian Pochet a cependant rappelé que c'étaient les Chefs de Service, Alexis en
l'occurrence pour la partie PFE, qui devaient s'acquitter de cette tâche (ils doivent être responsables de
leur budget et c'est la raison pour laquelle il leur revient l'exercice de commander ce dont ils ont
besoin).
Rôles succincts
- Le Chef de département initie l'exercice et il en est le A de RACI
(Accountable)
- Les Chefs de Service, aidés par les Chefs de projet, en sont les R
(Responsible)
Moments clefs
En général, on observe deux moments clefs rythmant la gestion
budgétaire annuelle d’un département : le Mid Term Process (± avril-mai) et le End of Year Process (±
septembre-octobre).
[h4]Mid Term Process (avril-mai)[/h4]
Ce moment, parfois appelé « révision budgétaire à
mi-parcours », consiste à vérifier la validité et la pertinence du budget initial en tenant compte des évolutions
constatées dans les projets. On évalue l’état d’avancement réel, on confronte prévisions et réalisations, et
l’on ajuste si nécessaire en anticipant les éventuels risques ou opportunités jusqu’à la fin de l'exercice. Ce
processus permet, lorsque l’organisation le prévoit, de procéder à des transferts internes ou à des ajustements
autorisés.
[h4]End of Year Process (septembre-octobre)[/h4]
Lors de cette étape, l’enjeu principal est double :
préparer le budget de l’année suivante et gérer les éventuels « carry-overs » (report de budget ou de
dépenses non engagées, lorsque cela est permis par la réglementation ou la politique de l’organisation). On
analyse les consommations, recense les reliquats, et on élabore une projection budgétaire pour l’exercice à venir,
en tenant compte des leçons tirées sur l’année écoulée, des perspectives nouvelles pour chaque projet et de leur
roadmap (adaptée si besoin).
Le EoY Process est ponctué par une acceptation ou rejet du budget présenté auquel cas
un retravail budgétaire est exigé.
OPEX et CAPEX
OPEX et CAPEX sont deux grandes familles de dépenses dans
la gestion budgétaire, simples à distinguer avec quelques exemples concrets.
[h4]OPEX : Dépenses de
fonctionnement[/h4]
OPEX signifie « Operating Expenditure », ou dépenses d’exploitation. Ce sont les
frais payés régulièrement pour faire tourner l’activité au jour le jour. Par exemple : payer l’électricité,
les salaires, l’entretien des équipements (serveurs, etc.), les achats de fournitures, les licences logiciel,
etc.
[h4]CAPEX : Dépenses d’investissement[/h4]
CAPEX veut dire « Capital Expenditure », ou dépenses
d’investissement. Ce sont les sommes dépensées ponctuellement pour acquérir ou améliorer des biens qui serviront
à long terme, comme l’achat d’une machine, la construction d’un bâtiment, un ordinateur neuf ou la création
d’un logiciel sur-mesure. Pour reprendre l’exemple de la voiture, acheter la voiture elle-même est un
investissement : c’est du CAPEX.
- OPEX = dépenses courantes, répétées, pour utiliser et entretenir
les choses.
- CAPEX = gros achats, investissements, qui apportent quelque chose d’utile pendant plusieurs
années qui est censé augmenter la valeur de l'organisation
Le budget est alloué
Le budget
alloué, il revient encore aux Chefs de service et Chefs de Projet de réaliser une projection mensuelle du budget. Le
but de cet exercice est d'aider le département "Finances" à prévoir la trésorerie nécessaire pour faire face aux
dépenses. Or, dans un projet et a fortiori dans un département, les dépenses sont excessivement rarement lisses,
égales de mois en mois. Dès lors, la projection mensuelle est une aide précieuse pour le département "Finances" qui
ne peut procéder à cette projection lui-même de manière intelligente ou réaliste car il ne dispose pas de cette
information.
La première projection a établir est celle de la vue des dépenses à engager à des moments clefs, par
exemple une période de renouvellement de licence, par exemple un renouvellement de licences AS-400, ou renouvellement
de licence DB2, ...
La deuxième projection mensuelle concerne des dépenses qu'on imagine se répéter de manière
égale de mois en mois, le paiement des prestations de consultants par exemple. Là, il est nécessaire de comprendre
que l'activité économique est inégalement répartie sur les mois de l'année. Intuitivement, on sait fort bien que
l'activité aux mois de juillet et août est bien moins intense qu'au mois de mars. Pour aider "Finances" on peut alors
se baser sur les indices d'activité économique tels que publiés sur Statbel. Pour la Belgique, voici quelques
données intéressantes :
- Mars est le seul mois de l'année avec une activité pleine (100%).
- Mai :
75% (holidays).
- Juillet : 60%.
- Août : 55%.
- Septembre : 80%.
Si on ne fait que
diviser le chiffre annuel par 12 pour trouver la dépense mensuelle, le service Finances aura des mauvaises surprises
lorsque les créances et les dépenses ne correspondront pas aux attentes. Il vaut mieux utiliser des statistiques
nationales d’activité (Statbel en Belgique est une bonne référence comme indiqué ci-dessus) pour modéliser les
budgets mensuels. Une fois qu’on additionne tout, l’activité effective totale sur une année n’est pas de douze
mois — elle se rapproche plutôt de 9,9 mois.
Une feuille Excel avec les formules justes a été élaborée. Eduard
ne l'a pas encore utilisée : on attend l'acceptation du budget pour l'utiliser. Cette feuille peut bien entendu servir
également à Alexis.
Mail envoyé avec la teneur ci-dessus à Alexis Lefebre, Eduard Creciun, Pierre Blauwart, copie
à Christian Pochet, Nicolas Forget, Pierre Paelinck et Pierre Bouchat |
| 26/09/2025 - 13:07 - Friday |
true |
Budget SAE 2026 |
Un budget tentatif réaliste a été établi pour 2026 par EdCr et PaBo. Ce budget est plus ou moins équivalent au
budget 2025, légèrement en baisse. Certaines hypothèses doivent cependant encore être vérifiées par EdCr (certains
postes, le daily rate moyen, le nb de jours en charge / an, ...).
Cela devrait être établi en début de semaine du
29/09 : EdCr travaille dessus.
On peut considérer que le travail est fait à 85%.
Il a été proposé à Alexis
Lefebvre de participer à la sessions mais Alexis a préféré disposer du template établi par EdCr et PaBo.
Ensuite,
quand on rappelle à AlLe que l'établissement du budget est une demande faite aux Chefs de service il y a une quinzaine
de jours, il feint de ne pas se souvenir et demande, par la suite, qu'une session soit montée juste pour lui mais je
n'en ai pas le temps (voir les mails ci-dessous)
From: BOENS Patrick
Sent: Wednesday, 24
September, 2025 2:54 PM
To: LEFEBVRE Alexis
Cc: CRECIUN Eduard ;
BLAUWART Pierre
Subject: Budget : convergence PFE - SAE
Hello Alexis,
Eduard et moi nous
nous apprêtons à établir le budget 2026 de SAE.
Eduard a établi une sorte de template qui permet de manipuler peu
de choses pour obtenir un budget réaliste, du moins en CAPEX.
Cela t’intéresse-t-il à partager la session que nous
avons prévue ce vendredi pour voir comment nous procédons, voire peut-être à utiliser toi-même le template
d’Eduard ?
Bien à toi,
Patrick
De : LEFEBVRE Alexis
Envoyé : mercredi 24 septembre
2025 15:23
À : BOENS Patrick
Cc : CRECIUN Eduard ; BLAUWART Pierre
Objet : RE: Budget : convergence PFE - SAE
Bonjour Patrick,
Partagez-moi déjà ce
template, ce sera plus efficace. Merci.
Alexis
|
| 26/09/2025 - 13:05 - Friday |
true |
CCS |
CCS : le décommissionnement. Il est nécessaire de se faire une réunion urgente sur le sujet car on a reçu cette
demande en Teams ...
DIERICKX Yvan
25-09-25 14:03
Hello Hello Eduard, je voudrais liquider le vieux serveur CCS vu
qu'on arrive fin 2025 et que c'etait programmé vu les trous de sécurité et que c'est plus maintenu =>tout est ok dans
le SAM maintenant pour qu'on le liquide ? appel détresse, afficheurs etc ? |
| 26/09/2025 - 09:15 - Friday |
true |
Assistance aux tests LV |
{IMPORTANT}
Le sujet est important car il est temps de préparer la bascule de LV dans SAM. La BU de LV est la plus
grande du TEC et donc il est important pour le département DSE d'avoir cette BU à bord. Or, la bascule, initialement
prévue pour le mois d'août, n'a pu tenir la ligne de temps pour une série de raisons propres à la BU (trop
d'activités différentes en même temps, grèves, absences, ...). La bascule a donc été repoussée à la 3ème
semaine d'octobre. C'est pour cette raison qu'on y travaille depuis 1 semaine (1 mois avant la bascule elle-même).
Un
meeting a été établi aujourd'hui (après 2 rappels) entre JeBe, PiBl et EdCr. Le sujet est "la présence de JeBe à
Liège pour assister cette BU dans la réalisation de ses tests concernant la liste MoSCoW".
Au terme de ce meeting,
PaBo devrait avoir la proposition de présence sur site (assistance de DSE à LV) en une période "rassemblée" (pas
étendue mais intense, comme un camp d'entraînement). Grâce à cette proposition, PaBo pourra alors établir avec
l'accord d'OlSt la présence effective de DSE-SAE.
Rappel de ce qui a été proposé :
1) On accompagne LV pendant 1,
2 ou 3 semaines de manière intensive (donc temps le plus court et le plus dense possible). À JeBe de voir avec EdCr et
Vina ; PaBo : passer l’info à OlSt et "négocoer" avec lui cette présence.
2) On ne parcourt QUE la liste MoSCow
(les points M)
3) On coche chaque ligne de la liste MoSCoW (test passé avec succès ou pas)
a. Si test OK, on passe
au test suivant
b. Si test pas OK, on place le sujet en haute priorité à l’équipe de Dev (le plus possible en
face-to-face ou communication directe – on documente par la suite. INSISTANCE sur ce point)
4) Dès que tous les
points M sont OK, nous faisons un rapport pour notre Management et CoPil
5) Discuter avec JeBe de l'utilisation d'un JMO
(Journal des Marches et Opérations - origine = militaire), rédigé au quotidien et relatant de manière factuelle les
faits, les mouvements de troupes, les combats, les reconnaissances, les ordres reçus ou donnés et tout autre
événement notable (encore une fois : origine militaire). Il s'agit d'un outil formel destiné à garder la trace
précise de l'activité d'une unité sur le terrain, sans commentaires subjectifs ni appréciations personnelles. Ici,
on applique cela à notre présence sur place sous la forme d'un journal qui, et c'est essentiel, doit être factuel. On
y consigne tous les éléments d'importance (arrivée, départ, prise de poste, délais observés, perte de focus,
...)
Outcome du meeting (outcome non-satisfaisant pour le Chef de projet/Chef de programme):
De : BECATTINI Jefferson
Envoyé : vendredi 26 septembre 2025 09:53
À : PAELINCK Pierre
; BOENS Patrick ; NAVEZ Vincent ; MARCOS Sara
; HACHEZ David
Cc : FORGET Nicolas ; BLAUWART
Pierre
Objet : Présence test & bascule LV
Bonjour à tous,
Après discussion avec OlSta,
nous avons mis à plat un planning de présence auprès de LV :
• Mercredi 01/10 : Présence et début des
tests
• Mercredi 08/10 : Présence et tests
• Du lundi 13 au vendredi 17 : Derniers tests + Accompagnement pour la
bascule
• Lundi 20/10 : Basculement
• Mardi 21 et mercredi 22 : Accompagnement Hypercare
• Du lundi 27 au jeudi 30
: Accompagnement Hypercare
• Lundi 03 et mardi 04 : Accompagnement Hypercare pour la rentrée
Nous pourrons ainsi
effectuer un maximum de tests en amont de la bascule et, surtout, assurer un suivi sérieux après celle-ci afin de
répondre rapidement aux problèmes éventuels et bloquants.
A dispo,
Cet outcome est non-satisfaisant pour le PM car
:
1) Les dates du 01/10 et 08/10 ne sont pas suffisamment ramassées et intenses. LV aura tout le temps d'ajouter de
nouveaux éléments entre ces deux dates
2) Le PM avait insisté sur le fait qu'il allait négocier les dates lui-même
auprès de LV, ce qu'il fait habituellement avec plus de détermination que JeBe et/ou Vina
3) Le PM ne voit pas du tout
l'implication du testing dans la démarche : NiDu
4) Le PM ne voit pas l'implication du développement dans l'urgence
des corrections éventuelles à effectuer ni sur l'engagement de mettre les nouvelles versions très rapidement en
production (ou sur staging, préférable)
5) Le PM ne voit pas sur quel environnement tout cela va se passer : Staging
ou Production
6) Si cela se passe sur Production, le PM indique qu'il faudra s'exonérer des meetings de Go/No Go
7) Le
PM estime que l'hypercare avec présence sur place est incohérent : c'est une période sans césure qu'il faut
8) Le PM
est satisfait avec les accompagnements lors de la rentrée des 03/11 et 04/11
9) Le PM ne voit aucune date de
confirmation/approbation finale de la bascule
|
| 25/09/2025 - 13:13 - Thursday |
true |
Demandes sous forme de fichier Excel |
Le fichier des demandes a été adapté sur base des demandes en friche dans dse.demande@letec.be. Nous couvrons 67
demandes (jusqu'à #DMD-2025-0067).
Nouvelle façon de gérer les demandes au niveau de SAM en cours de rédaction. Se
basera sur :
1) Les demandes de SAM sont rassemblées dans dse.demande@letec.be
2) Si des demandes arrivent chez des
membres de DSE et sont relatives à SAM, elles sont recopiées dans dse.demande@letec.be avec le nom de la personne à
l'origine de la demande et la date de la demande.
3) PaBo organise un meeting de review hebdomadaire des nouvelles
demandes avec ViNa, JeBe, et AlLe.
4) ViNa et JeBe rejettent, retardent ou acceptent les demandes pour SAE
5) AlLe
rejette, retarde ou accepte les demandes pour PFE
6) Les demandes sont FITA estimées par les POs
7) Si une demande
dépasse 10md d'effort, elle est remontée vers les 2 parties prenantes "Métier", "Management" pour arbitrage.
8) PaBo
informe les demandeurs de l'état de leur demande
9) PaBo organise un meeting mensuel avec le "Métier" et le
Management" pour les questions d'arbitrage
10) Aucune demande FreshService n'est traitée : fait partie d'un
fonctionnement alternatif
Voilà en substance ce que PaBo va défendre auprès de PiBl durant la semaine du 29/09. |
| 24/09/2025 - 08:50 - Wednesday |
true |
Plan d'action Bascule LV |
Hello Jeff,
Il faut regarder dans ton emploi du temps ce que tu peux consacrer à LV.
L’idée est d’aller à
Liège en « intensif » pendant une période de temps limitée avant le 20 octobre et de récolter les résultats de
leurs tests, point après point.
Voilà synthétiquement ce qu’il en est :
1) On accompagne LV pendant 1, 2 ou 3
semaines de manière intensive (donc temps le plus court et le plus dense possible). À toi de voir avec EdCr et Vina ;
à moi de passer l’info à OlSt.
2) On ne parcourt QUE la liste MoSCow (les points M)
3) On coche chaque ligne de la
liste MoSCoW (test OK ou pas OK)
a. Si test OK, on passe au suivant
b. Si test pas OK, on passe le sujet en haute
priorité à l’équipe de Dev (le plus possible en face-to-face ou communication directe – on documente par la
suite. J’insiste sur ce point)
4) Dès que tous les points M sont OK, nous faisons un rapport pour notre Management et
CoPil
Quant à parcourir la liste MoSCoW, il est impératif de ne jamais en dévier : pas se laisser embarquer dans
d’autres discussions interminables. On ne couvre que la liste MoSCoW dont voici le lien :
https://letecinside-my.sharepoint.com/:x:/r/personal/patrick_boens_letec_be/_layouts/15/Doc.aspx?sourcedoc=%7Bbd9206b3-9
ff5-4741-ac51-b3d82e535a47%7D&action=edit&wdorigin=Teams-HL.Sharing.ServerTransfer.LOF&wdexp=TEAMS-TREATMENT&wdhostclick
time=1742809060032&wdenableroaming=1&wdodb=1&wdlcid=fr&wdredirectionreason=Force_SingleStepBoot&wdinitialsession=9e38ba2
5-f689-1e47-4b55-5a98651f212c&wdrldsc=2&wdrldc=1&wdrldr=ContinueInExcel
@CRECIUN Eduard, @DUVIVIER Nicolas : j’ai
besoin d’un statut clair et définitif sur la ligne 25. En l’état, on dit « BLOCKED » mais la raison du «
BLOCKED » (colonne « Remarques ») ne me satisfait pas et elle n’est en aucun cas opposable à LV. Il me faut soit
une solution soit un statut qui dit « On ne le fera pas car bonne raison de ne pas le faire à expliquer ». Aussi,
toutes les remontées de tests KO faites par JeBe et/ou NiDu doivent être traitées comme l’emportant sur tous les
autres sujets « Run » du moment ; ils reçoivent la plus haute priorité automatiquement.
@KEINBORG Michael : La mise
en staging des corrections doit être réalisée le plus rapidement possible de telle sorte que JeBe puisse poursuivre
ses tests sans délai.
@BECATTINI Jefferson : J’ai besoin de ton input pour jeudi soir (temps qui sera nécessaire
selon toi). Si tu veux, on peut en parler de vive voix. Interdiction formelle de sortir de la liste MoSCoW (je sais …
cela va demander un peu de diplomatie avec les gars du dispatching et avec Olivier Stassart (OlSt).
@DUVIVIER Nicolas :
Nicolas, tu gères toute l’opération avec le point de vue du testing. C’est maintenant devenu capital.
Entendez-vous toi et Jefferson.
Est-ce que ce plan d’action convient à tout le monde ? Est-ce qu’il manque quelque
chose selon vous ?
Bien à vous,
Patrick
------------
Réaction de Pierre Blauwaert :
Merci pour le plan d'action
Patrick,
C'est bien cela, et je me permets de rajouter quelques éléments
Pouvez-vous me revenir d'ici fin de
journée avec le plan de charge théorique de Jeff sur cette mesure exceptionnelle ? (Mon but est de pouvoir donner à
Christian une estimation du support additionnel sur lequel on s'engage auprès de OlSt)
On doit pouvoir documenter si
les dispatcheur testent/jouent le jeu, (ou si uniquement les suppléants testent)
On doit pouvoir objectiver, tracer,
identifier ... J'abonde donc dans le sens de Patrick sur importance de la documentation,
Voici quelques pistes, je
vous laisse faire à votre sauce, mais j'aimerais que l'on puisse retrouver, si ce n 'est pas déjà le cas :
• L'info (Une colonne ? ) qui acte, le cas échéant, que nous avons livré et testé la fonctionnalité
• L'info
(Une colonne ?) qui acte (ou non), que le Métier a testé
• L'info (Une colonne ?) Qui acte (ou non), que la
fonctionnalité est validée => idéalement, même si pas validée car le métier demande des modifications, faire
valider que la fonctionnalité 'de base' fonctionne ...
• Si pas validée, la raison et clarification de la demande
de modification par le 'métier' (idéalement la plus-value de la demande, mais ce n'est pas notre combat à ce stade)
=> Le challenge se situe ici, dans la capacité à clarifier et surtout fixer une fois pour toute cette demande de
modifications => faire valider ces demandes de modifications par OlSt.
Nice to Have Jeff 🙂,
Pouvoir retrouver les
scenarios de tests effectués par le métier, et la personne qui a déroulé le scenario
Et idéalement également,
pouvoir fournir une mesure objectivée de la performance réseau
A votre disposition si vous voulez en
discuter
Pierre
-----------------
Réaction de Jeff avec réponses de Patrick dans le texte :
Merci, Jeff. Mes
réponses dans le texte.
De : BECATTINI Jefferson
Envoyé : mercredi 24 septembre 2025
10:04
À : BOENS Patrick ; CRECIUN Eduard ; DUVIVIER Nicolas
; NAVEZ Vincent ; MARCOS Sara ; HACHEZ David
; KEINBORG Michael
Cc : BLAUWART Pierre
Objet : Re: IMPORTANT et URGENT : Bascule LV
Bonjour Patrick,
On peut s’entendre demain
éventuellement mais à mon sens il faudrait à minima compter 7 jours de présence intensive. J’y suis déjà une
fois par semaine depuis bientôt 1 mois.
Vois avec Eduard et tes autres commitments quand tu peux te libérer et
pendant combien de temps. Moi je ne peux rien dire à OlSt tant que je n’ai pas une proposition de ta part (les
dates). 😉
Ce qui va être déterminant c’est le protocole de test à effectuer car à ce jour voilà comme ils
procèdent :
2 dispatcheurs travaillent sur la MC et traite les tickets revenant du terrain ;
Un dispatcheur est
rajouté en supplément afin de prendre et de traiter des tickets puis l’encoder dans la MC ;
Les retours se font donc
en travaillant « normalement » sans vraiment se focaliser sur des points en particulier.
Fais-toi aider de Nicolas.
Le but n’est pas de repasser SAE en revue, le but reste de tester les points de la liste MoSCoW et pour chaque point
Nicolas peut te dire comment le tester.
Un autre point que nous devons voir, avec OlSta plus particulièrement ce sont
leurs procédures. Actuellement ils ont encore des procédures qui peuvent être lourdes et pas forcément adaptée à
l’usage de Sam (Par ex : mettre un code fin sur le commentaire avant de clôturer un ticket - redondant).
Ce ne
devrait pas être le sujet de notre présence intensive sur la partie tests des éléments de la liste MoSCoW. Il est
nécessaire de rester concentré sur notre objectif.
Je pense donc qu’il est important aussi de travailler sur
l’optimisation du flux de travail et des processus afin que Sam, au delà de ses fonctionnalités, puisse être
utilisé de manière optimale.
Pas à ce stade, Jeff. Plus tard si on veut, mais pas maintenant.
J’ai demandé à
@CRECIUN Eduard la semaine dernière, mais je vais aussi vendredi au dispatch avec un développeur SAE (qui fait du Run)
afin de diagnostiquer rapidement si il y a des soucis et avoir un reporting technique en plus d’un reporting « humain
». Nous analyserons le réseau à ce moment là aussi.
Je veux bien un examen réseau car je veux leur couper toute
retraite concernant des pertes de connexion qu’on ne pourrait pas attribuer à une cause bien définie et dès lors
cela retombe sur SAM. C’est une partie essentielle de notre track de stabilisation et Eduard l’a noté
(Observability 2.0)
J’en profiterais pour (re)signifier nos engagement pris avec le MoScow et la non acceptation de
développement autre que ceux ci à OlSta.
Oui, à chaque fois, et compte sur moi pour passer le message à OlSt.
!
Je reste à dispo,
Bonne journée à tout le monde.
--------------
Réponse d'Eduard :
Hello,
Je suis d’accord
avec les commentaires de Patrick.
Pour vendredi ou autre jour c’est ok d’aller avec qq’un du RUN sans soucis
😉. Un Testeur en plus pourrait vous accompagner pour confirmer la liste de Moscow avec vous.
@BECATTINI Jefferson
si tu sens nécessaire je peux me déplacer aussi.
Bav,
Eduard
|
| 23/09/2025 - 14:13 - Tuesday |
false |
Décarbonation |
From: BOENS Patrick
Date: Tuesday, 23 September 2025 at 13:52
To: OLIKIER Jean-François
Cc: CRECIUN Eduard , BLAUWART Pierre
Subject: SoC
Bonjour Jean-François,
Je voulais t’informer de ce que le « SoC » a été
développé dans SAE et mis en production le 02/09 dernier.
As-tu d’autres demandes à prévoir pour le projet «
Décarbonation », soit pour la PFE, soit pour SAE ?
Bien à toi,
Patrick
----------------
Bonjour Patrick,
Un
grand merci pour cette info !
Il faudra m’expliquer ce qui a été exactement mis en place et quelles sont les
(pré-)conditions d’utilisation par le business (la ligne B2 de la BU de LV par exemple).
Dois-je comprendre que
l’intégration avec EventHub de Daimler est opérationnelle ou pourrait l’être ?
Au sujet d’une autre demande,
j’en ai une qui est relative à la remontée de la consommation des bus électriques.
Elle pourrait être remontée
soit dans le SAE soit dans SAP.
SAP en aura besoin pcq le métier veut comparer (consommation x km parcourus) et (kwh
consommés par les bornes pour charger les batteries).
Je suis en train d’organiser un workshop pour qualifier le
besoin et le décrire s’il est nécessaire.
Eduard sera invité.
Je te reviens dans les jours qui viennent.
Encore
merci,
cdlt,
JF.
|
| 23/09/2025 - 08:41 - Tuesday |
false |
Demande de meeting pour préparer l'accompagnement des Transporteurs |
Pour la partie « Transporteurs – Phase 2 », je pense que nous devrions nous mettre un petit meeting de préparation
détaillée de ce qu’on a l’intention de faire (quoi, quand, qui, où ?) : plan d’action.
Objectif(s)
:
Déterminer une ligne de temps avec le quoi, qui et où du début de la première mise en staging jusqu’à la mise
en production, entrée en phase d’hypercare, et sortie du mode hypercare.
Je vais organiser cela.
Bien à
vous,
Patrick
--------------
Organisation du meeting
Contexte : préparation de la release « Jason » (Transporteurs
2) et de l’accompagnement des Transporteurs
Objectif : Déterminer une ligne de temps avec le quoi, qui et où du
début de la première mise en staging jusqu’à la mise en production, entrée en phase d’hypercare, et sortie du
mode hypercare.
Sujets :
• Quand la partie Transporteurs 2 sera mise pour la première fois en Staging
?
• Prépare-t-on quelque chose avec les Transporteurs en environnement de Staging (attention, les Transporteurs
n’ont pas accès à tout en Staging) ?
• Quand livre-t-on la release « Jason » en production ? Dès que mise en
production, on passe en mode Hypercare (plus de personnes en capacité réservée sur le RUN pendant un certain temps.
Combien de personnes ? Pendant combien de temps ?
• Est-ce que la formation des Transporteurs se déroule sur Staging
ou en Prod (cfr. Remarques précédentes) ?
• Combien de temps dure cette formation ? Quand peut-on dire que ce qui a
été développé est utilisable par les Transporteurs ?
• Prévoit-on un accompagnement sur place ? Si oui ? Peut-on
établir un planning ?
• …
|
| 23/09/2025 - 08:00 - Tuesday |
true |
Maquettes clickables - Figma |
{IMPORTANT}
Conversation Teams entre PaBo et JeBe :
PaBo : Dis ... au niveau des maquettes, tu disais que les maquettes
sont testées par le Métier. Avec quoi fais-tu tes maquettes ?
Ce sont de petits prototypes ?
JeBe : Je fais les
maquettes avec Figma (design + prototype) si vraiment je dois pousser le prototype je peux passer sur Protopie ou
Framer
PaBo : OK ... c'est ce que je pensais
JeBe : Oui oui totalement clickable, comme ça le flux est testé et
les développeurs ont aussi le comportement précis
PaBo : Donc ... c'est un truc que les gens peuvent tester quand
même pas mal !
OK. Je pense que cela n'est pas connu de notre Management !
JeBe: Ah oui, le but c’est qu’à
chaque fois ce soit validé. Même si parfois on m’a refusé les tests parce qu’on avait « pas le temps »
Pourtant j’ai fais une tournée énorme de testing il y a 2 ans, avec les écrans, tous les matos dans toutes les BU
pour des journées entière..
Mais en effet je pense que ça n’avais pas dépassé Vincent Cordi
PaBo : On devrait
organiser une petite démo pour qu'ils comprennent comment ça marche et pourquoi ça diminue considérablement les
incertitudes sur le "qu'est-ce qu'il y a à faire ?" et "comment ça va marcher"
Donc ... cela diminue aussi
considérablement la partie "tests" qui vient ensuite. Je pense qu'il ne se rendent pas compte. De là nous avons des
questions qui ne sont plus appropriées comme les questions d'UAT.
Or, dans le cas de Transporteurs 2, la période de
mise à disposition sur Staging est vraiment une période d'UAT
JeBe : Avec plaisir, j’ai déjà eu à faire des
introductions à l’UX mais uniquement auprès du DSE. J’ai essayé d’expliquer à Christian plusieurs fois quand
il me posait des questions mais voilà je pense qu’il ne comprend toujours pas ce que je fais.
PaBo : La seule
différence c'est qu'on n'a pas un sign-off officiel
Or, dans le cas de Transporteurs 2, la période de mise à
disposition sur Staging est vraiment une période d'UAT
JeBe : Totalement et ce qui serait intéressant dans ces cas
c’est quand même d’avoir du monitoring comportemental sur les interfaces en plus..
PaBo :Oui, il faut organiser
cela pour Pierre Blauwaert, Nicolas Forget, et Christian Pochet
La seule personne "obligatoire" est Pierre Blauwaert;
NiFo et ChPo sont optionnels.
JeBe : Ça serait avec grand plaisir
PaBo : Le problème fondamental est qu'ils ne
savent pas comment on travaille et ils se posent des questions relatives à un mode "waterfall" et ne comprennent pas
qu'Agile fait tout cela aussi mais différemment. Il faut pouvoir les rassurer.
JeBe : Totalement d’accord, mais dans
tous les cas dis moi et je ferais un présentation avec un intro au processus UX et aux testing. J’ai même toutes
toutes les vidéos enregistrées des scénarios que nous avions tester pour la V3 + les différentes proposition
statiques qui ont pu être votée par les KU + l’implication avec le change en tant que facilitateur.
PaBo : Fonce
!
Cette conversation est considérée comme "importante" car elle permettrait d'éviter une série de malentendus
avec notre Management.
|
| 22/09/2025 - 13:30 - Monday |
true |
Démo Statham |
Démo de notre release Statham : pas beaucoup de personnes présentes mais problème potentiel de timing avec la dates
(conflit avec les fêtes de Wallonie).
Leçon apprise : il faut susciter David Hachez pour communiquer la démo par
mail (500 adresses email) + il faut "accrocher" le management pour qu'il vienne à la démo. |
| 19/09/2025 - 19:27 - Friday |
false |
Position GPS aléatoire |
Compte-rendu à lire depuis le bas car ici ce sont les réponses à des réponses à des réponses ...
La connexion GPS
(ou le GPS lui-même) semble ne pas remonter des informations correctes. SAE affiche ainsi des courses fantaisistes. Le
phénomène semble de plus en plus fréquent.
Ce n'est que dans le HT ?
Pour l'instant, dans le cadre de NextG,
l'équipe PFE consacre du temps à éliminer (réduire ?) les problèmes actuels de GPS (pour plus de détails, voir
avec Alexis ou Jérémie). Mais nous ne ferons les premiers tests réels que sur 50 bus (ce qui ne représente moins de
2% du parc total, donc si les problèmes reportés ci-dessous représentent encore moins que 2% des trajets, il se
pourrait qu'on ne détecte pas si le problème a été vraiment corrigé). Au mieux, les tests seront terminés dans la
deuxième partie de janvier.
________________________________________
De: NAVEZ Vincent
Envoyé: Vendredi 19 septembre 2025 15:04
À: BOUCHAT Pierre-Michel
; PAELINCK Pierre ; BOENS Patrick
Objet: RE: problèmes GPS
Le souci de transmission, je n'y crois pas. En tout cas, ce n'est
pas ce qui apparaît puisque nous avons dans la majorité des cas, des données dans ES.
Par contre, je voir les
coordonnées GPS qui sont à 0,0 ou qui sont figées et identiques de mesure en mesure, là je ne sais pas ce qu'il se
passe.
Le GPS qui se "fige" ? La PFE qui ne reçoit plus les infos mais qui logge la dernière info reçue ?
Les
positions GPS en dehors des routes : je me demande si les coordonnées notées dans les logs ou Ordibus sont celles du
GPS ? Comment comparer si bien identiques ?
Si identiques, pourquoi le GPS se met à déconner ? Vieillesse ? Chaleur ?
Humidité dans l'antenne extérieure sur le toit ? Câble de connexion de l'antenne ? Connecteurs ?
J'ai tenté de
proposer à Philippe Larcin de prendre un bus régulièrement avec ce souci et de le décortiquer avec leur équipe EII
qui s'occupe de la PFE. Mais je ne sais pas s'il va le faire.
Cynthia, la dame Seres de NR me disait qu'elle voyait
des symétries dans les tracés. La PFE fait-elle un calcul sur les valeurs reçues du GPS ? Je ne sais pas.
Impact
pour les clients ?
Le bus n'est pas localisé correctement. Les arrêts ne sont pas bien détectés. Les données
affichées sur le site ou l'app doivent donc être pas propres ou erronées.
Dans letec finder sur internet, j'y ai vu
des bus rouler en temps réel au milieu des champs. Côté image de marque, ça risque de ne pas être super top ☹
De : BOUCHAT Pierre-Michel
Envoyé : vendredi 19 septembre 2025 14:57
À : NAVEZ
Vincent ; PAELINCK Pierre ; BOENS Patrick
Objet : RE: problèmes GPS
Ca m’inquiète.
Nous risquons de passer un temps considérable
à essayer de comprendre ce qui se passe sans nécessairement pouvoir donner une réponse correcte.
Ca risque de venir
de l’opérateur ou de notre matériel ou de nos logiciels.
Un fameux casse-tête.
Quel est l’impact pour nos
clients de ce type de « dysfonctionnement » ? Je crains que ça dure encore quelques temps avant de changer nos PFE et
nos blocs communication. En espérant que ce soit une réponse à ces problèmes…
De : NAVEZ Vincent
Envoyé : vendredi 19 septembre 2025 14:50
À : BOUCHAT Pierre-Michel
; PAELINCK Pierre ; BOENS Patrick
Objet : TR: problèmes GPS
Pour votre info.
De : NAVEZ Vincent
Envoyé : vendredi 19
septembre 2025 14:48
À : STEYLEMANS Cynthia
Cc : LEFEBVRE Alexis
; CHEVALIER Jérémie ; CRECIUN Eduard ;
MARCOS Sara
Objet : RE: problèmes GPS
Bonjour Cynthia,
Dans l'ordre des bus que tu as
mentionné dans ton mail.
Pour le 101010.
L'agent a fait sa PDS avec la voiture 0. Ce qui fait que quand tu cherches
l'historique depuis le service matériel, sam recherche des tracés sur le bus 101010, képi 388 et ODM = 177 et il ne
trouve pas car dans les données ODM = 0 parce que l'agent n'a pas ouvert son service correctement. Si tu supprimes
l'ODM et le képi par exemple, pour ne chercher que le bus 101010, tu trouves le tracé qui me semble ok.
Pour le
101235.
Je ne trouve pas de PDS en début de service (quand l'agent fait une PDS, on a un message type = 0). Le premier
message reçu du bus est un type 32 = détection d'arrêt. N501bmb = Bouge Pêcherie, c'est l'arrêt que la PFE renvoie
sans cesse.
Je vois aussi que la date du GPS est en 1970. Lien avec le fait que la position soit toujours (0,0) ? Je ne
sais pas.
Pour le 101263.
Ici, je trouve une PDS à 15h08. Pas de PDS le matin.
On voit que l'agent tente de se
recaler. Mais quand la PFE détecte un arrêt, les coordonnées sont parfois du côté de Charleroi. Pour la ligne E84,
comme tu le dis, on dirait que les relevés GPS sont en miroir vertical avec une rotation de -90°. C'est assez
étrange. On a aussi les coordonnées GPS qui se placent au milieu de bois, maisons, etc.
Pour le 100134.
Je trouve
une PDS à 6h15, sur la bonne voiture (163). Par contre aucun tracé, même en ne cherchant que le bus, sans le
matricule et sans l'ODM dans la carto.
Quand je cherche dans nos données, je trouve bien des infos, j'en déduis que la
transmission de données fonctionnait bien mais au niveau des coordonnées GPS, je ne trouve que les coordonnées
(0,0).
Pour quelle raison, je ne sais pas dire.
Pour le 101263.
Il y a bien des coordonnées dans les données mais
quand je prends une valeur au hasard, par exemple celle avec la flèche, je trouve bien le bus au milieu des champs.
Exactement ce qui est affiché dans la carto sam avec le bus qui passe "à travers tout" :
Pourquoi ? Je ne sais
pas.
Pour le 100871.
Le bus fait Dinant Namur, Namur Dinant. Pas de tracé GPS. Les positions dans les données sont
toutes à 0,0.
Sur la carto, si je visualise les arrêts détectés, je vois que l'agent tente de se recaler. Quand il
le fait à Gare des bus de Namur, vers 14h10, on voit bien que la position du bus n'est pas ok. Le bus est bien à la
gare des bus de Namur mais les coordonnées le placent près de Andenne.
Dans le réalisé de sam, on voit une
précision de 15000m…
Pourquoi la PFE nous envoie des coordonnées qui ne sont pas là où est le bus, pourquoi
les données GPS sont tellement lointaines de la position réelle du bus ? Je ne sais pas non plus.
Pour le 101239.
Si
le bus ne donne des données qu'en Wifi, il faut faire vérifier son modem data.
On a bien des données après-midi, sur
la 2e partie du service mais rien du matin.
Là, il faudrait faire vérifier le bus peut-être. Mais c'est étrange
qu'après-midi, tout semble avoir été correctement.
Pour le 100134.
Là aussi, le tracé est à travers tout,
l'agent qui tente de se recaler et les coordonnées GPS qui sont très loin de là où il devrait être. On voit des
arrêts détectés totalement en dehors de sa ligne quand l'agent tente de se recaler.
De nouveau, je ne sais pas
pourquoi les coordonnées que nous recevons de la PFE qui les reçoit du GPS sont totalement "à côté de la plaque".
Pour les positions des bus qui sont hors route, ça rejoint ce que le directeur technique du HT me signalait la semaine
dernière (à propos du 3858 en régie si mes souvenirs sont bons) et ce que Jean-Marc (Seres HT) m'expliquait hier
après-midi. Ils sont également surpris de voir que beaucoup de véhicules semblent "se balader à travers tout" et que
cela apparaît plutôt simultanément.
Je comprends votre difficulté pour contrôler qu'un voyage a bien été
exécuté et les arrêts bien desservis.
Dans les cas que tu me soumets, j'avoue avoir grande peine à dire oui le
voyage a été bien fait ou pas ☹
Je mets Alexis et Jérémie de l'équipe PFE en copie pour le cas où ils
pourraient nous donner plus de détails.
N'hésite pas à m'envoyer d'autres cas étranges au niveau de la
localisation de vos véhicules transporteurs.
Vincent
De : STEYLEMANS Cynthia
Envoyé : jeudi 18 septembre 2025 16:23
À : NAVEZ Vincent
Objet
: problèmes GPS
Bonjour Vincent,
Voici quelques exemples que j’ai noté :
101010/7173 99000388 405177 02-09-25 Pas de tracé
101235/7179 99000374 407305 03-09-25 Pas de
PFE
101263/7185 99002800 408394 03-09-25 Tracé à l'envers
01-09-25 402153 131 4 100134/7142 N02 Latour Pas de carte
géolocalisation,pas de données
02-09-25 408194 E84 16 101263/7185 N08 Latour Problème de tracé GPS ->pas de
données
02-09-25 402141 433 19 - 22 100871/7162 N07 Latour Pas de tracé GPS -> pas de
données
02-09-25 407110 27 Toute la journée 101239/7183 N07 Latour Ne se connecte que au
WIFI
02-09-25 402157 69 1 100134/7142 N02 Latour Tracé GPS fantaisiste ou inexistant
Je serai occupée les jours
prochains avec l’analyse des offres du marché public, mais dès que je reprendrai le traitement des anomalies, je
noterai systématiquement les anomalies et te les enverrai chaque fois en fin de semaine.
J’espère que cela vous
aidera à découvrir ce qui cloche.
Merci d’avance pour votre aide,
Cynthia Steylemans
Cynthia
Steylemans DIRECTION NAMUR-LUXEMBOURG
Gestionnaire administrative
Services Sous-traités Avenue de Stassart 12 •
5000 Namur
081/72.08.56
Cynthia.Steylemans@letec.be
LETEC.BE
|
| 19/09/2025 - 19:16 - Friday |
true |
Cadastre SAM |
Meeting de cadastre (choses à faire) pour SAM (2025 et 2026). Demande d'établir une roadmap à trois ans. Cette
demande n'a jamais été formulée au Chef de Programme. La demande qui a été formulée a été de passer en revue la
liste des demandes en souffrance. On doit imaginer que la demande du business s'est affinée avec le temps dans le
contexte de l'initiative d'assessment d'un produit étagère.
Voici le compte-rendu de cette réunion :
<<<
À
REMPLIR
>>>
Une deuxième passe du cadastre est nécessaire pour au moins justifier le budget PFE et surtout SAE de
2026. Il est demandé au programme de racler les tiroirs à la recherche de toutes les demandes introduites (nécessité
d'avoir une gestion de la demande -- mais process arrêté par NiFo : point remonté à PiBl : le programme SAM n'a pas
à établir un processus, le programme a à suivre un processus DSE. Period!)
La deuxième passe doit avoir lieu avant
le CoPil du 09/10. Le mécanisme des deux passes est conforme aux meetings #1 et #2 de la semaine de transition entre
deux cycles. Le Chef de programme propose d'en faire des meetings récurrents toutes les 13 semaines pour asseoir la
pratique et ainsi constituer les échanges bidirectionnels entre le Chef de programme, le Métier (pas suscité ici), le
Management, et les Utilisateurs (collecte de développement des besoins).
|
| 19/09/2025 - 14:25 - Friday |
false |
Étude sur les incidents entre le 01-01-2025 et 12-03-2025 |
Une première évolution est remarquée dans les incidents SAM (SAE et PFE) :
- Du 02-01-2025 au 11-03-2025, soit sur
une période de 69 jour, on recense 129 incidents, soit 1.87 incidents/service requests par jour.
- Du 13-03-2025 au
11-09-2025, soit sur une période de 183 jours, on recense 211 incidents, soit 1.15 incidents/service requests par
jour.
En combiné, du 02-01-2025 au 19-09-2025, on est à 348 incidents, soit 1.34 incidents par jour.
L'amélioration
est donc conséquente !!! |
| 19/09/2025 - 13:00 - Friday |
false |
1-2-1 Eduard |
Niko-Nico : +1 (avec remarques) (échelle = -1; 0 ou 1)
1) L'équipe évolue bien
2) Quelle différence entre le début
et aujourd'hui
3) Très heureux de l'initiative de l'équipe qui a elle-même organisé un meeting de gestion des
tickets dans Azure DevOps : proche de l'auto-organizing
4) Quelques doutes sur le temps de travail de certains membres
de l'équipe mais travail fait
5) Moins de bugs qu'avant; c'est plus confortable
|
| 19/09/2025 - 09:30 - Friday |
true |
Échanges cadastre 2025-2026 SAM |
Réunion Cadastre
Cette réunion est un flux continu d’échanges entre différentes personnes.
Ces personnes sont
représentées par leurs initiales :
AlLe Alexis Lefebvre
ChPo Christian Pochet
EdCr Eduard Creciun
JeBe Jefferson
Becattini
NiFo Nicolas Forget
PaBo Patrick Boens
PiBl Pierre Blauwart
PaBo :
Les 3 dernières pages ce sont les
demandes en souffrance, ce qui a été encodé/sauvegardé par Pierre Bouchat et que j'avais trouvé intéressant de
parcourir. C'est le reliquat non traité des demandes qui nous sont parvenues et que le département DSE a parquées
sans plus y revenir par la suite et dont, plic ploc, nous recevons des piqûres de rappel de la part des demandeurs et
qui causent le sentiment déplaisant d'un manque de suivi de la part de DSE. C'est ce que Christophe Leurident a
demandé à recevoir quand il a appris que cela existait.
ChPo :
Après les demandes en souffrance, y a-t-il autre chose
de prévu ?
PaBo :
Non.
ChPo :
Alors juste par rapport à ça parce que je vais voir si ça répond à tout.
Je souhaite
pouvoir établir une roadmap de tout le programme SAM, une roadmap à trois ans qui représente tout le cycle de vie du
programme SAM.
PaBo :
Ce que nous fournissons ici c'est une vue de ce qui est annoncé pour 2025, reste du cycle 3 et
contenu du cycle 4, avec pour ce dernier 2 inconnues qui concernent les décommissionnements de CCS et Géoloc.
Nous
avons, par ailleurs, des suggestions pour 2026 (voir colonne de statut) provenant de la liste des demandes en souffrance
que vous avez indiqué vouloir parcourir vous-mêmes afin d'exercer votre volonté d'imprimer la direction du programme
et des projets qui le composent.
Nous n’avions pas l’objectif d’établir une feuille de route à 3 ans. Nous
entendons votre demande et nous nous mettons en position de la rencontrer.
ChPo :
Pour la partie PFE j'ai effectivement
la vision souhaitée avec tout ce que cela contient jusqu'à la fin du projet, en 2030 : blocs comm., le comptage
passagers, girouettes Lumiplan, et autres releases.
[Néanmoins, on verra plus tard que les sujets n’ont pas été
détaillés ce qui sera demandé en fin de meeting]
PaBo :
Non, même cette partie PFE ne va pas jusqu'au bout du
programme, soit 2030, même s'il est vrai que la partie Blocs Comm., elle, s'étend jusque fin 2026. Le planning vu en
Steerco Blocs Comm. le démontre même si quelques doutes ont été exprimés sur la faisabilité de ce planning et
surtout de ses dates charnière dont sa date de fin. Pour SAE, nous attendons les conclusions de ce workshop pour
effectivement nourrir l'année 2026 avec VOS priorités tout en rappelant que nous formulons des propositions que nous
sommes prêts à défendre.
ChPo :
Vous n'avez pas de vision d'un refactoring de code ou d'autres choses. Tout le cycle
de vie de SAE est compris ici ? En caricaturant, puisque le but est de créer une roadmap — remarque PaBo ... cet
objectif n'a pas été communiqué, ce qui a été communiqué c'est ... "on veut choisir ce sur quoi vous allez
travailler" — avec du court, du moyen et du long terme. Imaginons qu'à la fin de cette réunion on dise "toutes les
demandes en souffrance on ne les fait pas, cela veut dire que le projet est fini ?"
PaBo :
Nous avons des propositions
présentées dans le tableau synthétique de Jefferson et ces propositions sont essentiellement basées sur notre
encours présent (ce qui se trouve dans le backlog) et le tableau des demandes en souffrance. Il existe par ailleurs une
série d'autres demandes qui faute de Demand Management efficace ne sont pas centralisées : mails, vieux tickets du
backlog, canaux Teams, ... Sur base de ce que nous connaissons aujourd'hui nous avons une vue construite jusqu'à la fin
de l'année 2025 pour SAE et un ensemble de propositions pour les 6 premiers mois de l'année 2026 (tableau des demandes
en souffrance qui nous a été demandé d'examiner ensemble). Pour PFE, les choses sont claires jusque fin 2026, du
moins pour ce qui est des blocs comm. Pour les autres sujets PFE nous avons aussi des candidats, par exemple Comptage
Passager, mais pas de vue arrêtée sur une date de release. Revenant à SAE, suivant les sujets qui seront pris de la
liste des demandes en souffrance mais également des sous-jacents des décommissionnements CCS et Géoloc, il est
parfaitement raisonnable d'étendre la roadmap jusqu'à fin 2026, ce qui donnerait une situation symétrique entre PFE
et SAE. Entre-temps il y aura aussi le résultat de l'assessment qui impactera grandement le déroulé de 2026, plus
pour SAE que PFE d'ailleurs.
ChPo :
Ici il faudrait être en mesure d'établir une vue à 3 ans, une vue qui dise, pour
SAM, on va encore faire ceci et cela.
PaBo :
Oui c'est une vue qu'il sera possible de construire sur base des
conclusions de l'assessment. Rien que la conclusion, oui ou non pour le produit étagère, impose une vue stricte au
niveau des nouvelles fonctionnalités (stop si on va vers un produit étagère), et là il faudra prendre une posture
sur (1) que faut-il faire pour que SAE passe en full maintenance ? (2) pour quel horizon et (3) avec quelle voilure en
termes d'équipe. Le même raisonnement s'applique à PFE. Dans la foulée, voire simultanément, il est nécessaire de
préparer les périodes de chevauchement "SAE-étagère" et "PFE-étagère" pour déboucher sur la période "full
étagère".
ChPo et PiBl :
Non, ce n'est pas vous qui avez besoin de l'assessment, c'est l'assessment qui a besoin de la
vision à 3 ans, la roadmap.
Ici il y a quand même un malaise :
1) On dit à l'équipe SAM qu'elle ne peut pas décider
par elle-même de ce qu'il y a à faire
2) L'équipe SAM prépare donc une série de sujets sur lesquels le management
peut statuer
3) Le Management indique ensuite que l'équipe SAE devrait proposer une roadmap (donc une liste de sujets
déterminés et déjà décidés)
4) Qui alors propose les sujets au final, l'équipe SAE ou le Management?
5) Un manque
de dialogue bidirectionnel entre les POs et les 3 parties prenantes est constaté (constat effectué d’ailleurs
antérieurement au meeting, dès le 19/08).
PiBl :
L'assessment pourrait dire que début 2027, telle et telle chose sont
prévues mais qu'en définitive le produit étagère le fera. On a besoin de savoir où on va, de savoir quels sont les
points d'évolution que vous prévoyez.
PaBo :
Au terme de ce meeting on va savoir, au moins partiellement, où on va,
au moins sur la première partie 2026. Par contre, je suis surpris que le sponsor ne puisse pas dresser les plans de ce
qu'il considère que le produit SAM, SAE en particulier, doit faire. Ici, sont réunis sponsor et Product Owners à qui
il revient la tâche de définir le produit et son évolution tandis que le chef de programme s'assure qu'effectivement
cette vision soit traduite par les équipes, le Chef de service s'assurant, lui, que les ressources nécessaires à la
construction (le build) soient allouées et disponibles, ainsi que les ressources nécessaires à son support (Run).
Pour l'instant, une vision à trois ans ne peut être garantie parce que personne n'y a travaillé.
ChPo :
OK, c'est pas
grave, ce qui important c'est d'avancer et de comprendre les objectifs poursuivis, c'est de déterminer les périmètres
qu'il faut encore couvrir dans les années qui viennent.
PaBo :
Ok. Revenons à nos cycles. Nous sommes dans le cycle 3.
Pour rappel, un cycle c'est 13 semaines, très précisément un trimestre. Par trimestre on se donne des objectifs et
nos sprints sont orientés de telle sorte que nous couvrions nos objectifs. Le cycle 3 est orienté "Stabilisation" et
"Transporteurs" tandis que le cycle 4 est orienté "Transporteurs" essentiellement et "Décommissionnements" (on verra
plus loin). Ce qui reste à livrer pour le cycle 3 c'est "Radio Charleroi".
ChPo :
Reprenons à la première ligne, la
release Atlas.
PaBo :
La release Atlas est derrière nous. C'est ce qui a été livré le 29/07, une release qui a été
démontrée (grosse démo) et qui comportait le gros des efforts en matière de stabilisation dont la suppression des
effets de bord de mémoire.
ChPo :
La release « Ardentia », c'est fait ?
PaBo :
Non, c'est la bascule LV, qui en soi
n'est pas une release mais plutôt un ensemble d'efforts récurrents qui, on l'espère, se concrétiseront par la
montée à bord de LV pour la partie SAE. D'ailleurs, à ce propos, nous organisons un meeting de crise ce mardi 23/09
car nous avons le sentiment de plus en plus appuyé que LV prépare sa non-montée à bord.
Puis nous avons la release
Statham qui vient d'être mise en production, et qui est la première partie Transporteurs.
ChPo :
Qui est faite en
développement ?
PaBo :
Non, livrée en production !
ChPo :
Pour moi, livré, veut dire que les Transporteurs
l'utilisent. Le projet ne se limite pas à dire que la partie est développé me et a été mise en production.
PaBo
:
Statham est mis en production, est livré, tandis que la partie Change Management se prend cours au mois de
novembre.
ChPo :
Donc, ce n'est pas livré. Le wording est important car cela crée des conflits au niveau métier.
C'est peut-être mis en production mais pas livré. Du côté du projet, il y a encore un gros boulot à faire d'un
point de vue Change avec les équipes métier pour que cela puisse être utilisé. On risque d'avoir le sujet qui nous
revient en développement ce qui se passe d’ailleurs à LV depuis 6 mois. Et donc pour "Transporteurs", dans un worst
case scenario, on risque la même chose que LV.
EdCr :
Dans notre tête, "livré" veut dire "développé, testé et
déployé en production".
ChPo :
Et quand tu vas dire cela à l'Administrateur Général tu penses que c'est cela que
ça voudra dire ?
PiBl :
Le projet est en production mais il n'est pas Live !
ChPo :
Votre wording est compliqué parce
qu'il permet des interprétations différentes. Est-ce que le produit peut encore subir des modifications ?
EdCr :
Oui,
comme dans tous les produits.
ChPo :
Exemple de l'achat d'un frigo. Il s'ensuit que JeBe et EdCr rebondissent sur
l'exemple pour démontrer la justesse de leur position.
Un projet ne s'arrête pas quand c'est fait; un projet est fait
lorsque le Run est mis en place. Et là le Run il n'y est pas.
Ici, il y a confusion entre un produit complètement
défini ou un produit livré par parties, chaque partie ayant une valeur métier indéniable qui justifie des mises à
disposition partielles, ce qui est le cas de l'ensemble du produit SAE. Quant au Run, oui ... il y est car l'équipe
assure déjà le Change (nouvelles choses à développer) ET le Run simultanément (maintenir et supporter ce qui est
déjà livré et utilisé) ce qui a d’ailleurs fait l’objet d’une réorganisation de l’équipe pour le
permettre.
S'ensuit une longue discussion sur la définition de "livrer" dans laquelle s'invitent aussi le débat du
Change Management, le User Acceptance Testing et la période d'hypercare.
Cette discussion se conclut par une précision
intéressante : la release Statham, celle du 29/07, "Transporteurs" donc, est une release en lecture (pas de création,
suppression, modification de données) qui ne nécessite aucun plan d'accompagnement de Change Management. La release
qui s'annonce, Jason, elle, permet les modifications. Dès lors, c'est pour cette release que le plan d'accompagnement
au changement de David Hachez et Sara Marcos doit se mettre en place. C'est prévu au mois de novembre, le plan étant
déjà élaboré.
On peut alors revenir sur la release du 07/10 dédiée à Radio Charleroi. Cette release tombe juste
avant le prochain CoPil, le 09/10. La démo de Radio Charleroi s'organise le 20 octobre, soit ± 15 jours après la
release. Donc pour fin octobre, nous sommes en Run pour la partie Radio Charleroi.
Ensuite commence le cycle 4 avec ses
sujets déjà déterminés mais pas de date de release fixée. Les dates de release d’un cycle sont fixées dans les
15 premiers jours du cycle. Le cycle 4 commence le 29/09 et se termine le 26/12/2025.
Interrogations concernant les
décommissionnements CCS et Géoloc indiqués comme sujets du cycle 4 mais pour lesquels des dépendances avec d'autres
projets doivent être examinées. Des décisions concernant ces décommissionnements doivent être prises au prochain
CoPil et donc il faut préparer ces décisions. Demande de ChPo d'avoir un slide. À minima, nous représenterons le
tableau qui avait été présenté au CoPil du 24 avril 2025 (slide 29) : ce slide présente une situation globale pour
Géoloc et CCS.
CCS : problématique G4S (appels de secours). Expliquer cette problématique et ses causes et voir
quelles sont nos options. Si on envisage de reprendre cette partie, alors il faut des estimations FITA dont il faudra
tenir compte dans le budget (prévu pour mercredi 24/09 mais repoussé à vendredi 26/09). Exemple de décision attendue
en CoPil : "non, étant donné le coût, tant pis pour BW, on ne va pas le faire !" Pour chaque option qu'on présente
et qui implique un coût de développement, il faut que le coût approximatif soit fourni. Pour chaque option il faut
aussi connaître l'impact et le sentiment que cela crée. Par exemple, il se pourrait que vivre sans G4S soit
intolérable.
Pour Transporteurs (release Jason prévue pour le 31/12 (date à confirmer lors des 15 premiers jour du
cycle 4, donc pour le vendredi 10 octobre ... en fait nous aurons une date à présenter au CoPil du 09/10). "Livré"
veut-il dire "testé par le métier ?"
ChPo :
On revient à la définition du mot "livré" qui a suscité les débats
antérieurs. Par exemple, Liège - Verviers, est-ce qu'ils testent.
PaBo :
Un distinguo est à opérer ici. LV ... oui
il y a une véritable phase d'UAT au sens où tu l'entends, Christian. Cette phase a d'ailleurs démarré le 01/07 mais
pour des questions internes à LV ils n'ont pu se tenir à ces dates et elles sont maintenant remises à Octobre
2025.
Pour une release comme Atlas (stabilisation) aucune phase d'UAT n'a été planifiée malgré l'ampleur de la
release. Cela est dû à la nature de la release.
Pour la release Statham, là non plus aucune phase d'UAT n'a été
planifiée avec le Métier. C'est parce que la release est une release en "lecture" seulement (pas CRUD).
Pour la
release Jason, un plan d'accompagnement est prévu puisque à côté du R, on a aussi CUD de CRUD. Le plan
d'accompagnement se pratique sur Staging et donc, de facto, il y a une phase UAT.
Il convient également de noter que
c'est le PO qui donne son go final pour une release sur base de SON acceptance du produit et comme il est le
représentant du Métier son acceptance vaut acceptance du Métier et des Utilisateurs.
ChPo :
Ma question c'est, quand
c'est livré, est-ce que c'est testé par le Métier ?
EdCr :
"Livré" veut dire qu'on a une version finale qui est
construite et testée et par l'équipe de test. J'ai fait une réunion pour le change pour préparer la manière
d’intégrer justement l'équipe seres : ils viennent et ils interagissent déjà avec l'application ... ils la testent
en fait.
ChPo :
Il y a un risque que l'Acceptance ne soit pas là.
PaBo :
Non ... c'est l'apanage du PO qui effectue ses
tests qui valent UAT. Les tests du PO peuvent être complétés par des tests Métier spécifiques qui ont lieu sur
l'environnement de Staging.
JeBe :
N'oublions pas que toutes les maquettes sont revues par le Métier, et ce qui a été
établi dans les maquettes est testé directement sur les maquettes : ce qui est "designé" est ce qui est
"développé", donc est en partie "pré-testé".
ChPo :
Donc, revenant au planning, le 31/12 on aura une version livrée
et on entrera dans une phase de Final Acceptance par le Métier (Seres) et puis on va entrer dans la phase Go Live, donc
avec une période de Hypercare de 6 mois.
ViNa :
Si je peux me permettre, Transporteurs phase 1 c'est la mise à
disposition d'un outil équivalent à ce qu'ils avaient avec Géoloc, c'est-à-dire la cartographie temps réel et la
cartographie historique. D'un point de vue "Tests", ils ne découvrent rien de nouveau, c'est juste présenté
différemment.
Note à introduire dans les minutes de meeting :
Dès la livraison en production, la partie développée
et mise à disposition entre directement en mode Run, tant du point de vue des 1ère, 2ème et 3ème lignes de support :
c'est un hypercare direct et permanent. L'équipe est organisée pour ce mode de travail avec une capacité réservée
pour le Run. Ce mode de travail s'appelle le mode "You Build It, You Run It". Ce mode est existant depuis le début pour
les équipes, tant PFE que SAE, mais a fait l’objet d’une révision en mai-juin 2025.
Et pour Transporteurs phase 2,
celle qui est dans le cycle 4, c'est déjà testé et accepté par les utilisateurs « régie » et ce qui a testé est
ce qui va être mis à disposition, une fonctionnalité destinée à leur faciliter la vie, régie et transporteurs.
Avec ce que nous allons livrer il leur sera permis d'annuler des voyages en temps réel, quelque chose qui existe depuis
très longtemps en régie.
ChPo :
Il y a un autre élément qui sont les tests de charge. On va aller en production au
31/12, puis on ne va pas avoir de contrôle du « comment on va aller LIVE », puis on va avoir un pic d’utilisation
(écriture et accès). Quid de cet effet-là ? C’est pour cela que cela inquiète ChPo car même si le Métier l’a
validé cela n’empêche pas des retours intempestifs des utilisateurs par la suite. La phase de tests permet aussi de
pointer les derniers manquements, les choses que le Métier ou les utilisateurs ont oublié de préciser au
départ.
PaBo :
Effectivement, nous n’avons pas de tests de charge, LSP (Load, Stress and Performance). C’est un
trou dans la raquette du développement qui doit être adressé. Cependant, les LSP ne sont pas liés à l’UAT car
cela relève, habituellement, de besoins non-fonctionnels. Ces éléments devraient d’ailleurs faire partie d’une
HLTLS (High-Level Testing and Launching Strategy) que nous ne sommes pas encore arrivés à mettre en place. Nous
retenons cet élément pour compléter le track « Stabilisation ».
Comme indiqué, la période de mise à disposition
de l’appli en staging permet de tenir une phase de test, tant pour l’équipe SAE que pour les BUs. C’est ce qui
était et est toujours prévu avec LV : notre appli étant testable en staging par LV depuis le 01/07.
ChPo :
Cela veut
dire que le 31/12 le gros des développements de Transporteurs sont finis et puis on entre dans une phase d’acceptance
à partir de ce moment-là. Je demande cela pour qu’on ne me dise pas au mois de février, « tiens où on en est avec
Transporteurs ? et qu’on découvre que la moitié des loueurs n’utilisent pas la release ».
PaBo :
Un plan
d’action sera établi (une réunion a été fixée au 01/10) pour détailler la mise en production de la release «
Jason ». Ce plan d’action comprendra toutes les actions à entreprendre au niveau du plan de Change (jouer avec le
produit en production car pas d’accès à tous les outils pour les Transporteurs en-dehors de l’environnement de
prod, début et fin des formations, période hypercare, etc.)
ChPo :
Prochain sujet : Géoloc. Pourquoi utilise-t-on
encore Géoloc en régie ?
EdCr :
Il y a des liens étroits entre CCS et Géoloc. Par exemple le « ack » qui fait
l’acquittement des messages est fait partiellement par Géoloc (pour les BUs de Liège, Hainaut et Caleroi) et
partiellement par CCS (pour BUs BW et NL). Une autre fonctionnalité est celle de l’envoi de messages avec les
téléphones que les PFE peuvent appeler. Là aussi, une partie c’est CCS et l’autre c’est Géoloc. Il faut
adapter la partie GDS.
En fait, Géoloc et CSS font des opérations « behind the scene » : si on coupe d’un côté,
cela a des conséquences de l’autre.
ChPo :
Cela veut donc dire que la phase de cartographie n’est pas encore
terminée.
EdCr :
Cartographie, c’est une page uniquement pour les Dispatching.
S’ensuit une discussion sur les
fonctionnalités cachées et sur la fonctionnalité traduite sous forme de User Story (En tant que …). Finalement, le
mot décommissionnement de Géoloc est erroné car il ne s’agit que de couper l’interface Web ce qui ne saurait
s’apparenter à un décommissionnement total de l’outil : en arrière-plan, il continuerait à faire ce qu’il fait
tandis que sa partie « interface » (les cartes) pourraient être assumées par SAE : les fonctionnalités
d’arrière-plan, elles, sont encore nécessaires.
ChPo :
Cela veut donc dire que l’outil Géoloc doit toujours être
maintenu. Si Géoloc plante, cela veut dire que vous devez le remettre en route, c’est-à-dire en assurer la
maintenance en mode Run.
EdCr :
Il y a probablement incompréhension. La cartographie SAM … c’est une page web. À
partir du moment où c’est dans SAE, on peut couper la page web correspondante dans Géoloc. Géoloc fait deux choses
:
• Une carte présentée sur une page web
• Des choses automatiques qui sont faites via GDS (l’acquittement de
messages et l’envoi de messages téléphoniques)
ChPo :
Ce que je veux dire c’est que si on continue à avoir besoin
de tous ces autres outils alors même que vous me dites que la fonctionnalité a été implémentée dans SAE c’est
qu’il doit y avoir des fonctionnalités qui restent à développer ou à maintenir, sinon, je pourrais procéder au
décommissionnement. Or, ce n’est pas le cas puisqu’il y a des fonctionnalités « behind the scene » qui ne sont
pas couvertes par SAE. De plus, dans le plan de releases, c’est comme si on avait deux streams indépendants alors
qu’ils semblent intrinsèquement liés (CCS et Géoloc) : il vaut mieux présenter cela sous la forme d’un seul
bloc.
EdCr :
Il y a un élément à garder à l’esprit : GDS c’est le cœur de ce que la PFE envoie. Une position
GPS, cela passe par GDS. Un appel de détresse, cela passe par GDS. C’est le cœur du temps réel et c’est aussi le
cœur de Géoloc.
ChPo :
Alors, si on ne peut pas s’en passer, il faut que cette partie rentre dans SAM. Il faut alors
modifier les explications du plan de releases.
NiFo :
Géoloc cela tourne sur quoi ? Alertes de l’infra disant que
cela tourne sur des serveurs qui ne sont plus supportés. J’ai demandé de faire en sorte que cela soit
décommissionné car plus supporté et personne n’a réagi. Géoloc et CCS tournent apparemment sur le même serveur,
donc même combat !
ChPo :
Qui entretient Géoloc pour l’instant ? C’est vous ! Parce que c’est un produit SAE.
Cela a été développé par « Solutions Spécifiques », donc par Michael Flahaut. L’infra ne fait que s’assurer
que Géoloc continue à tourner mais nous prévient qu’un jour Géoloc ne tournera plus. Alors, on a dit à l’Infra
« Ne vous en faites pas, on le décommissionne » et maintenant on est en train de dire qu’il va falloir le garder.
Il faudra penser à intégrer dans SAM toutes les fonctionnalités « behind the scene » qui vont nous permettre de
vraiment décommissionner CCS et Géoloc.
EdCr :
Une partie doit être déléguée à PFE pour la partie développée en
C++ (réception des messages en temps réel).
AlLe :
Préanalyse de Jérémie sur le sujet. Demanderait 1 mois de
travail (FITA) et aurait des impacts côté SAE. Point à creuser mais il faut synchroniser les développements entre
SAE et PFE.
ChPo :
Dans une prochaine réunion, je veux avoir une image complète de ce qu’il y a à faire, côté PFE
et côté SAE pour arriver à complètement couper Géoloc. Je veux une description de chaque fonctionnalité qu’il
faut soit couper soit reconstruire ailleurs dans SAM. Nécessité de dire quelle fonctionnalité est dans quel outil
(Géoloc ou CCS) et qui dépend de qui (Géoloc dépend de CCS ou inversement)
NiFo :
PiBl doit nourrir les schémas
présentés dans un meeting avec Alain Couniot avec des fonctionnalités X, Y, et Z dépendantes de tel et tel logiciel.
Certaines parties doivent venir des plans de l’équipe sur ces fonctionnalités à réintégrer dans SAM. Il faut
aussi disposer d’un état « Infra » des services (sur quoi ça tourne ? …)
ChPo :
Service Agent : prochain point
dans le plan de releases. Très demandé. Sous contrôle : analyse faite, approbation du chef de produit, pas de date
précise, estimation FITA à obtenir.
NiFo :
Discussion sur les estimations et la manière de prendre les choses dans le
sprint. PaBo explique que les estimations du temps de construction est fait lors du Sprint Planning et sur base d’une
découpe en User Stories. En soi, l’équipe ne dispose pas d’’estimations à la grosse louche. Un feature peut
contenir plusieurs User Stories. Ce sont les User Stories qui forment un engagement de l’équipe sur ce que contient
un Sprint et c’est la tâche du PO de découper un feature en US. Cet exercice d’estimation est fait durant le
Sprint Planning au terme duquel on sait ce que contiendra un sprint. Les releases, elles, sont déterminées en fonction
de features (plus grosse granularité) qui font sens à être mis à disposition. Par exemple, on peut avoir un feature
qui concerne des voyages découpé en 4 user stories : visualisation d’un voyage, suppression d’un voyage, création
d’un voyage, suppression d’un voyage. Deux US peuvent être développées dans un Sprint et deux autres dans un
autre Sprint. Par contre, on ne fera de release que lorsque les 4 US sont réunies. Juste un exemple ! À aucun moment
nous n’avons une estimation « à la grosse louche » mais il est entendu que l’équipe SAM comprend votre besoin de
disposer d’estimations FITA pour prendre une décision éclairée sur ce qu’il faut faire vs. ce qu’on pourrait
faire (costs, benefits, risks).
ChPo :
Nécessité de détailler les tracks rapportés par PFE : aller dans un détail
HL des sujets, détaillé, mais pas trop, quelque chose qui convient au Management et au CoPil.
Dès que nous sommes
entrés dans le tableau Excel des demandes en souffrance, les notes de réunion ont été prises directement dans le
tableau. Il faut donc se reporter au tableau.
Le meeting se conclut par dire que les points typiquement PFE (Bloc Comm.
Girouettes, Release 2.3.0, et peut-être d’autres comme « traductions ») doivent être détaillés par Alexis.
ChPo
:
Voyez-vous autre chose à mettre dans les choses à faire en 2026 ? Car pour moi, là, je n’ai pas de quoi justifier
le budget de 2m€.
PaBo :
Côté SAE, la stabilisation n’est pas finie mais nous n’avions pas assez de bande
passante pour prendre ces points dans le cycle 4. Parmi les sujets à couvrir il y a la partie « data et bases de
données », la partie « monitoring » pour couvrir les principes essentiels de l’observability 2.0, les
déploiements automatiques, le testing end-to-end entre PFE et SAE, stabilité des connexions, …
ChPo :
Alors, il faut
les mettre dedans parce que c’est maintenant qu’on fait les budgets.
S’invite la question du Demand Management
lorsqu’on indique que l’ensemble de la feuille Excel est ce qui a alimenté l’exercice mais que par ailleurs nous
recevons aussi des demandes par email qui soit restent dans une boîte email (dse.demande@leec.be) et ne sont pas
gérées, soit migrent dans le backlog produit du SAE sans être examinées en détail car il n’y a pas la bande
passante pour prendre toutes les demandes et les qualifier. Enfin, il y a encore des demandes dans des boîtes mail
personnelles, chez Eduard, chez Vincent, chez Jefferson, dans les rapports de réunion avec LV, …
|
| 18/09/2025 - 14:00 - Thursday |
false |
1-2-1 Jonathan |
Niko-Nico : +1 (avec remarques) (échelle = -1; 0 ou 1)
Aime travailler de manière structurée avec un cadre
déterminé. Plein d'initiatives ont été prises dans le passé mais aucune n'est terminée
Sprint Planning à
améliorer
Manque de communication entre PFE et SAE, mais même au sein de SAE : ne sait par exemple pas exactement ce
qui est dans une release (qu'est-ce qu'on met en prod ?)
Ne voudrait pas être en interview face à PaBo : questions
trop déstabilisantes |
| 18/09/2025 - 13:54 - Thursday |
true |
Meeting d'alignement sur gestion des tickets dans backlog SAE |
Un important meeting a eu lieu à l'initiative même de l'équipe SAE concernant la gestion des tickets, meeting appelé
par Jonathan et Gaspar.
Les retours concernant ce meeting sont excessivement positifs. Il reste maintenant à voir si
le nouveau processus peut être documenté et vérifier qu'il donne des résultats (construction plus rapide ? moins de
bugs ? ...) |
| 18/09/2025 - 13:30 - Thursday |
false |
1-2-1 Solange |
Niko-Nico : +1 (mais avec remarques) (échelle = -1; 0 ou 1)
Très heureuse d'avoir été affectée au Run : cela lui
permet de passer à autre chose que Transporteurs
Équipe évolue bien selon elle avec une belle progression depuis le
mois de mars et en particulier depuis juin/juillet |
| 18/09/2025 - 13:00 - Thursday |
false |
1-2-1 Nicolas Duvivier |
Nous a rejoint il y a déjà ±4 mois
NiDu trouve qu'il y a un net mieux dans l'évolution de l'équipe
NiDu est
d'accord sur le constat que l'équipe est encore en mode "storming". Par exemple, il n'est pas encore possible de tout
se dire en rétro.
Bastien pas là, cela a aider à diminuer les tensions
Remarque à PaBo : perception que PaBo monte
parfois vite dans les tours
Niko-Nico : +1 (mais avec remarques) (échelle = -1; 0 ou 1) |
| 18/09/2025 - 11:47 - Thursday |
true |
Bascule LV |
Le 17/09 à 12h00, Vincent Navez a fait un mail résumé du meeting P153 avec LV (Olivier Stassart).
Suite à ce mail,
le risque que LV ne bascule pas augmente considérablement pour préparer un NO GO.
Un meeting de crise a été établi
pour traiter du sujet sur deux bases claires :
1) Liste MoSCoW fermée : nécessité de déterminer ce que sont de
nouvelles demandes et ... les rejeter
2) Position ferme de refus des nouveautés avec soutien du Management
Meeting
positionné le 23/09/2025 pour discuter de cela (point remonté en Staff Management du 18/09) |
| 18/09/2025 - 07:25 - Thursday |
false |
PSR-20250916.docx |
Project Status Report envoyé, PSR-20250916.docx, du 31/07/2025 au 16/09/2025 |
| 18/09/2025 - 07:23 - Thursday |
false |
Congés personnels |
Congés du 22/09 au 26/09 |
| 18/09/2025 - 07:23 - Thursday |
false |
Congés personnels |
Congés du 06/10 au 10/10 |
| 17/09/2025 - 18:00 - Wednesday |
true |
Steerco NextG du 17/09/2025 |
Agenda :
- Planning et date provisoire de fin des installations
- Prototype : Délai
- Offre PM
- Offre assemblage /
installation
- Plateforme de Staging et Test
Meeting notes:
Validation du Planning et dates clés du projet :
- Marc
Capelle, Christian Pochet, Nicolas Forget, Pierre Paelinck, Fabrice Respilleux et d'autres ont discuté en détail du
planning du projet, de la faisabilité de la date de fin d'installation en octobre 2026, des étapes intermédiaires, et
des contraintes liées à la disponibilité du matériel et à la validation par le Codir.
Présentation du planning :
- Marc a présenté le planning général, en insistant sur la nécessité d'un 'technology freeze' pour éviter des
modifications continues et garantir une date de fin réaliste. Il a proposé d'adapter les phases du projet, soit en
supprimant certaines, soit en les réalisant en parallèle, pour respecter les délais.
Remise en question de la date
d'octobre 2026 :
- Christian Pochet et Nicolas Forget ont exprimé leurs doutes sur la faisabilité du planning,
soulignant que le matériel ne serait pas disponible à temps pour commencer le roll-out en février, et que le planning
actuel ne tenait pas compte de toutes les contraintes logistiques et matérielles.
Découpage des Projets et
Disponibilité du Matériel :
- Il a été clarifié que les 440 MC 100 commandés étaient destinés à un autre
projet (PFE_V2) et non au rétrofit des anciens bus, ce qui a mené à la suggestion de lancer rapidement une commande
de 1000 platines pour éviter des retards supplémentaires.
Validation par le Codir :
- Christian Pochet a insisté sur
l'importance d'intégrer la validation du Codir comme un jalon clé dans le planning, car aucune commande majeure ne
peut être passée sans cette validation, qui dépend elle-même des résultats des tests sur les prototypes.
Gestion
des tests, prototypes et offres :
- Fabrice, Pierre Paelinck, Marc Capelle et Christian Pochet ont abordé la gestion
des prototypes, la planification des tests, la dépendance des offres à la validation technique, et la nécessité de
fournir rapidement des offres pour 50, 500 et l'ensemble des équipements.
Tests sur Prototypes et Validation technique
:
- Les tests sur deux prototypes MC 100 sont prévus pour valider la solution technique ; la décision de passer à la
production de 50 puis 500 équipements dépendra des résultats de ces tests, attendus pour fin octobre.
Dépendance des
Offres à la validation :
- Fabrice a expliqué que les offres de prix pour les PCB, platines et assemblages dépendent
du 'freeze' technologique et des retours des fournisseurs, mais qu'une offre ferme pour 50 équipements pourra être
fournie pour le 30/09.
Commande Anticipée de composants :
- Pierre Paelinck a proposé d'anticiper la commande de
certains composants pour gagner du temps, même avant la validation finale des tests, ce qui a été accepté sous
réserve de pouvoir ajuster en cas de modifications mineures.
Multiplicité des Offres demandées :
- Christian
Pochet demande trois offres distinctes : une pour 50 équipements, une pour 500, et une offre globale pour l'ensemble du
projet, afin de pouvoir avancer par lots et s'adapter aux validations progressives.
Organisation de l’Assemblage et
de l’installation :
- Fabrice, Marc, Pierre et Christian Pochet ont détaillé le processus industriel
d’assemblage et d’installation des équipements, la logistique, la documentation, et la possibilité pour certaines
BU de réaliser elles-mêmes l’installation sous conditions.
Processus Industriel d’assemblage :
- Fabrice a
décrit le processus d’assemblage centralisé chez le fournisseur de tôlerie, incluant la réception des composants,
l’assemblage, le staging logiciel, les tests, l’étiquetage et le stockage, afin d’assurer la traçabilité et la
qualité.
Installation sur Site et documentation :
- L’installation dans les bus sera réalisée par des
techniciens qui effectueront le fine tuning sur place, avec une documentation précise des réglages pour chaque bus,
permettant un suivi et une maintenance ultérieure efficaces.
Rôle des BU dans l’installation :
- Certaines BU,
comme celle de Liège, souhaitent réaliser elles-mêmes l’installation ; cela est accepté à condition de suivre le
même processus et la même documentation, mais Proximus ne sera alors pas responsable de la garantie sur
l’installation.
Livraison et logistique :
- La logistique prévoit la livraison centralisée des équipements
assemblés, avec la possibilité pour les BU de venir chercher le matériel ou de l’expédier, et la nécessité de
clarifier les coûts et modalités de transport.
Contraintes Logistiques et Optimisation du planning :
- Les
participants ont analysé les contraintes pratiques liées à la disponibilité des bus, la gestion des dépôts, la
coordination avec les loueurs, et les moyens d’optimiser le planning via l’utilisation des plannings de maintenance
et de réparation.
Disponibilité des Bus et dépôts :
- Le planning d’installation doit tenir compte de la
disponibilité réelle des bus dans les dépôts, des contraintes d’exploitation, et de la capacité à fournir un
nombre suffisant de bus chaque jour pour respecter le rythme d’installation.
Coordination avec les loueurs :
- La
gestion des bus loués ajoute une complexité supplémentaire, car certaines installations devront se faire chez les
loueurs ou nécessiteront leur venue dans les dépôts, ce qui impose une coordination spécifique.
Optimisation par le
Planning de maintenance :
- Il a été proposé d’utiliser les plannings de maintenance et de contrôle technique
des bus pour planifier les installations, permettant de profiter des périodes d’immobilisation déjà prévues et
d’optimiser le déroulement du projet.
Variables d’ajustement :
- Fabrice a souligné que le nombre d’équipes
d’installation, la capacité des dépôts, et la flexibilité des plannings sont des variables d’ajustement qui
permettront d’affiner le planning au fur et à mesure de l’avancement du projet.
Prochaines Étapes et Points de
suivi :
- L’équipe a convenu de fournir les offres la semaine suivante, d’organiser des réunions avec les BU
pour affiner les paramètres, et de planifier un nouveau point de suivi début octobre pour valider les avancées et
ajuster le planning.
Fourniture des Offres :
- Fabrice et Marc se sont engagés à fournir les offres pour 50, 500 et
l’ensemble des équipements pour au plus tard le 30/09, conditionnant la suite du projet à la réception de ces
éléments.
Rencontres avec les BU :
- Les réunions avec les différentes BU sont prévues à partir du 24/09 pour
recueillir les informations sur la disponibilité des bus, les contraintes spécifiques et valider les modalités
d’installation.
Prochain Point de Suivi :
- Un nouveau point de suivi a été fixé pour début octobre, afin de
faire le bilan sur les offres reçues, les retours des BU, et d’ajuster le planning en conséquence.
Follow-up
tasks:
1. Offre pour 50 boîtes à tartines :
Fournir une offre détaillée pour 50 boîtes à tartines incluant
les pièces, le PCB, l’assemblage et la livraison avec date estimée.
Action : Fabrice Respilleux, Marc
Capelle
2. Offre pour un premier lot de 500 blocs complets :
Élaborer une offre spécifique pour un premier lot
de 500 blocs complets, incluant coûts et modalités de livraison.
Action : Fabrice Respilleux, Marc Capelle
3. Offre
globale pour l’ensemble du projet :
Préparer une offre globale couvrant l’ensemble des bus à équiper
(environ 2700), avec découpage par lots et assemblage inclus.
Action : Fabrice Respilleux, Marc Capelle
4. Distinction
des coûts d’installation par lot :
Distinguer dans l’offre les coûts d’installation par lot (par exemple,
de 1 à 5 bus, de 6 à 10 bus) et selon le moment (jour, nuit, week-end).
Action : Fabrice Respilleux, Marc
Capelle
5. Documentation du processus d’assemblage et installation :
Fournir une documentation écrite
(présentation PowerPoint) détaillant le processus d’assemblage et d’installation pour présentation au Codir.
Action : Fabrice Respilleux, Marc Capelle
6. Affinement du planning avec paramètres réels :
Affiner le
planning d’installation en intégrant les retours des fournisseurs sur les délais, les prix définitifs et les
contraintes des BU.
Action : Philippe Culot en collaboration avec Pierre Paelinck
7. Planification des visites BU :
Organiser et réaliser les visites dans les différentes BU pour collecter les informations sur les contraintes et
disponibilités des bus.
Action : Pierre Paelinck
8. Intégration du plan de maintenance dans le planning :
Analyser la possibilité d’intégrer le plan de maintenance des bus dans le planning d’installation pour
optimiser la disponibilité.
Action : Pierre Paelinck
-------------------
Mail envoyé à Pierre Paelinck après le
Steerco (copie Pierre Blauwaert)
Salut Pierre,
La plus grande variable d’ajustement « planning » est la portion de
bus qui sera faite par les BUs elles-mêmes.
En cela, la dichotomie « régie » vs. « loueurs » est essentielle pour
pouvoir estimer le nb réel de bus dont PXS ne doit pas assurer l’installation (1700 ? vraiment ? loueurs et régie
?). Si on imagine un nb de 1000 bus (c’est un exemple) dont il ne faudrait pas que Proximus s’occupe, c’est autant
de temps gagné dans le planning et ton chemin critique deviendra alors … l’assemblage, packaging et livraison aux
BUs car ce temps-là est incompressible (le temps que tu gagnerais serait ± proportionnel à 1000 / 2874, soit pas loin
de 35% du temps d’installation sur base de cette hypothèse).
Par ailleurs, il y a lieu de distinguer les éléments
d’une commande qui ne sont pas à mettre en doute (un MC100 par exemple) et les éléments qui eux ne sont pas encore
totalement sûrs (le PCB par exemple). Tout ce qui peut être commandé en respectant les règles en vigueur peut
l’être (philosophie « no regret move »). Je pense – mais n’en suis pas totalement certain – que cela peut
aussi constituer une variable d’ajustement dans le planning, mineure celle-là par rapport à la première, je te
l’accorde.
Concernant la date du 06/10 qui devrait être la date à partir de laquelle la partie « software » du
MC100 serait prête, je t’invite à reboucler avec Dimitri qui me semble bien seul à œuvrer sur cette matière. Au
demeurant, il me semble que la partie « software » comprend aussi un routeur, élément sur lequel Maxime est occupé,
me semble-t-il. Sur ces deux éléments, dispose-t-on d’une liste exhaustive de ce qu’il y a à faire par qui pour
quand ? Si oui, je vais mettre cela dans un .mpp (ou alors … tu me dis que cela existe dans le .mpp de PXS et alors je
me calque là-dessus). En tout état de cause, j’aimerais vérifier que nous sommes bien en capacité à 100% (ou pas
loin) pour ces deux ressources de telle sorte que je puisse être assuré qu’effectivement la partie « software » à
réaliser pour le bloc comm. sera effectivement garantie pour une date fixe car … c’est un autre chemin critique :
sans cela la partie assemblage (déjà partie critique) ne pourra pas s’exécuter comme nous l’espérons (à
vérifier avec PXS).
En conclusion, même si je ne peux parfaitement estimer la vraisemblance du planning présenté,
je n’ai pas autant de réserves que Nicolas et Christian surtout eu égard au point 1 mentionné. Il faut absolument
clarifier ces points pour notre management car je sens que Christian est assez inquiet sur ce sujet. Je suis à ta
disposition pour en parler car je n’ai évidemment pas tous les points en vue.
Bien à toi,
Patrick
|
| 17/09/2025 - 13:30 - Wednesday |
true |
Élaboration budget réel 2025 |
Un premier budget réel a été élaboré par Eduard et Patrick. Le budget est dit réel car il s'appuie sur la base de
la situation réelle (nb de ressources et périodes d'assignation). Les deux grandes inconnues sont le calcul de l'OPEX
et le taux journalier moyen positionné à 650€/jour. Le budget sera présenté en mode brouillon au Staff Management
meeting de jeudi 18/09/2025.
Se basant sur des hypothèses réalistes il peut servir de canevas de base pour estimer le
budget de 2026 à voilure ± identique.
Il est à noter qu'une nouvelle ressource est demandée pour renforcer les
Business Analysts qui depuis le départ de Dominique Delfosse et la nomination d'Eduard Creciun au poste de chef de
service sont réduits à ½ FTE.
Cependant, la configuration actuelle ne semble pas permettre l'incorporation d'une
nouvelle ressource cette année si on veut respecter le budget.
Ce sera à vérifier et il devrait être tenu compte du
fait que la publication d'une offre BA, la tenue des interviews, le choix du candidat et la signature de contrat
pourraient ne pas permettre l'accueil de la nouvelle ressource encore en 2025.
Total CAPEX 1.933.100,00 € vs
1.919.000 € (forecast)
Total OPEX 73.400,00 €
TOTAL 2.006.500,00 € vs 2.060.000 € (forecast)
|
| 17/09/2025 - 13:00 - Wednesday |
true |
Mise en prod v3.9 |
Pour rappel : mise en production de la version 3.9 de SAM/SAE ce 17/09 à 10h.
La version 3.9 adressait les points
suivants :
Possibilité d'appeler un bus depuis le module Fiche véhicule, cela crée un ticket dans le module
Alertes.
Possibilité de supprimer un numéro de bus dans la qualification d'un Voyage non détecté avec
sous-catégorie 'voyage non exécuté'.
Correction sonnerie permanente.
Envoi message par SMS.
Edition des groupes de
lignes à nouveau possible avec toutes les lignes enregistrées.
Centrage de la cartographie sur le Belgique à
l'ouverture du module carto Temps réel.
Amélioration des bus grisés dans le module carto Temps réel.
Amélioration
de Carrefour à Feux : augmentation du nombre de lignes, correctif de date et heure.
Noms des agents (si autorisé)
disponibles dans le module Alertes.
Les deux modules cartographiques prêts pour être mis à disposition des
Transporteurs.
INFO DE MICHAEL KEINBORG
Message de Michael : Mise en prod sans incident et rapide.
NAVEZ
Vincent17-09-25 11:18
Bonjour Tout le monde,
La mise en production du correctif a été faite par Michaël qui a
géré d'une main de maître 😍
J'étais dans sam et je n'ai rien remarqué 🥳
Belle journée à tous !
|
| 17/09/2025 - 12:00 - Wednesday |
true |
P153 - Bascule LV |
Mail de Vincent Navez
Salut à tous,
Voici mes petites notes de la réunion avec Olivier S de ce 17/09/25 matin.
J'ai
mis en surligné les questions qu'il se pose et souhaiterait un retour.
Sonnerie dans les Alertes : corrigé
aujourd'hui 10h.
Quand on ouvre un ticket, on a bien l'enveloppe qui s'affiche mais il continue à
clignoter.
Vérifier si un ticket devops a été créé. Ca ne devrait plus clignoter quand un utilisateur ouvre le
ticket et que l'enveloppe apparaît.
Numéros de téléphone agents, 3 champs dans Hastus mais seulement 1 dans
sam.
Possible de ramener les 3 champs dans sam pour avoir la certitude de visualiser le numéro de GSM du conducteur
?
J'ai répondu qu'il était aussi possible d'encoder le numéro de GSM de l'agent dans le champ 1 qui est importé dans
Hastus mais Olivier S répond que ça risque d'être compliqué de faire cela dans Hastus.
Quelle est la fréquence de
l'import des numéros de téléphone des agents dans sam ?
Script des trip undetected : pourquoi ça s'est arrêté
?
Quel était le souci ?
Filtre dans les Alertes pour sélectionner plusieurs champs ou exclure une qualification bien
précise par exemple. Faire le filtre multi select en prio pour Alertes. Possible ? Si oui, pour avant le basculement
?
Ca leur permettrait de retirer de la vue Alertes les Voyages non détectés.
François Laurent qui ne voit pas les
noms des agents : corrigé avec le fix d'aujourd'hui.
Erreur dans le lien vers la main courante ? 17/09/25 8h44.
Voir ci-dessus.
Flux coupé de sam prod vers MCT ?
Les étiquettes et vignettes qui donnent des infos différentes.
Que pouvons-nous faire ?
(Pas d'accès dans la conversation de la réunion, je n'ai pas les captures d'écran
d'Olivier.)
En gros, les étiquettes donnent des infos différentes des vignettes. Et aussi différentes des vignettes
dans Géoloc.
Déconnexions de l'outil ? Différences entre Géoloc et sam au niveau carto. Les bus sont parfois au
mauvais endroit dans sam alors que dans Géoloc ils sont au bon endroit.
Jeff passera avec un dev dans 2 semaines. CDS
vérifiera le réseau avant le basculement. Faire un audit du réseau |
| 17/09/2025 - 11:45 - Wednesday |
true |
PFE - Production PFE V2 - MC100 |
40 MC100 reçues mais le reste n'est pas encore commandé. En cause, un firmware imminent qui concerne le MC100 et on
aimerait en bénéficier.
Par ailleurs, les plans ont été modifiés et il n'est plus question à ce stade de faire
assembler la version "complète" (autrefois platine voussoir, HMI et GSM Voice, càd MC100). Le plan est maintenant de
faire assembler la partie "complète" par Proximus : dépendance du track "Bloc Comm" ou aussi appelé "NextG" avec
Pierre Paelinck.
À ce stade on laisse donc Alexandre continuer sur les blocs HMI (129 assemblés).
Question qui se
pose : autrefois, il était prévu d'entamer la livraison des blocs complets dans le courant du mois de novembre donc
... où devons-nous faire la livraison prochaine des HMI et voussoirs (on va manquer de place au niveau -2). Arrangement
avec Proximus ? |
| 17/09/2025 - 07:02 - Wednesday |
false |
Liste de documents ralisés |
Voici une liste de documents établis pour améliorer la méthode et la rigueur des métiers des équipes PFE et SAE
depuis le 01/03/2025 :
Chef de projet (old) : Proposé le 27/03/2025
Chef de projet Waterfall et Agile : Proposé le
27/03/2025
Cycle Planning (draft 20250625 ) : Proposé le 15/05/2025
Daily Scrum : Proposé le 07/08/2025
Développeur :
Proposé le 24/03/2025
DevSecOps : Proposé le 01/04/2025
Epics, Features, User Stories and Tasks : Proposé le
25/07/2025
Go-No Go : Proposé le 19/08/2025
HLTLS (High Level Testing and Launching Strategy) : Proposé le
08/05/2025
La bonne démo : Proposé le 24/06/2025
Processus de préparation d'une démo : Proposé le
23/07/2025
Processus de gestion des demandes : Proposé le 28/04/2025
Processus de mise en production - SAE : proposé
le 14/05/2025
Processus générique de mise en production : proposé le 07/07/2025
Processus SAE de suivis des AMIS
(feedbacks) : proposé le 28/04/2025
Product Owner : proposé le 27/03/2025
Scrum Master : proposé le 20/03/2025
Test
Manager : proposé le 24/03/2025
Testeur : proposé le 24/03/2025
Ce travail est réalisé en conformité avec la
règle #1 de la Charte des Managers |
| 16/09/2025 - 18:05 - Tuesday |
true |
Travail du Chef de Projet / Chef de Programme |
Christian Pochet et Nicolas Forget expriment des doutes sur la gestion de programme et de projets conduite par Patrick
Boens. Christian Pochet souhaite que le scope soit mieux maîtrisé par le PM afin que lorsqu'il lui pose une question
il dispose de réponses plus élaborées au lieu d'un renvoi vers Eduard Creciun ou Vincent Navez. Ce sentiment est
appuyé par Nicolas Forget pour qui le Chef de projet est l'unique personne qui exerce une responsabilité totale, quoi
et quand (livraison).
Un conflit apparaît entre Agile et Waterfall et le PM, Patrick Boens, est prié d'établir une
approche pour remédier à la situation.
Le renouvellement du contrat de Patrick Boens est remis en question. |
| 16/09/2025 - 18:00 - Tuesday |
true |
Besoin Analyste |
Dans le setup de l'équipe il manque quelqu'un qui puisse prendre les analyses. Dans le temps, Eduard Creciun s'en
occupait quasiment sur base d'un temps plein et Dominique Delfosse était plus spécifiquement sur la partie Hastus.
Cela nous faisait deux ressources disponibles pour les analyses.
Par contre, depuis le mois de mai, il a été demandé
à Eduard de prendre la fonction de Chef de Service qu'il cumule aujourd'hui avec les analyses (analyses qu'il ne peut
plus faire que de manière partielle).
Pierre Bouchat a plusieurs fois mis en lumière le besoin de renforcer l'équipe
d'analystes mais jusqu'à présent ce besoin n'a pas été rencontré.
Nous avons donc un risque de ne pouvoir nous
lancer dans les analyses requises pour l'an prochain (2026) au niveau SAE. Les analyses pour les sujets de 2025 sont
soit déjà réalisées soit bien entamées et ne requièrent pas d'attention spécifique.
Nonobstant le besoin, il
sera nécessaire de voir si le budget nous permet de prendre ce poste. Ce sera examiné le mercredi 1 octobre 2025.
|
| 16/09/2025 - 13:24 - Tuesday |
false |
PFE : sprint courant (Weeks 38-40) |
Sprint 2025 Weeks 38-40 (courant) ... préparation de ce qui est prévu
• Finaliser/valider simulateur
GPS
• Trouver problème GPS NextG V1 (Teltonika)
• Tests MC-100 V1 et V2
• Problème de demande de rappel qui ne
passe pas au vert à Liège
• Release pour correction de demande de rappel (V2)
Pour les releases PFE :
• V1
o 25.7-2 le 26 août 2025 (Sprint Weeks 35-37)
o 25.7-3 le 11 septembre 2025 (Sprint weeks 35-37)
• V2
o 2.2.1 le 19 août 2025 (Sprint Weeks 32-34)
o 2.2.2 le 4 septembre 2025 (Sprint Weeks 35-37)
|
| 16/09/2025 - 12:24 - Tuesday |
true |
Analyse FreshService PFE du 13-03-2025 au 11-09-2025 |
Le rapport va de 13-03-2025 au 11-09-2025, soit sur une période de 183 jours. Entre ces deux dates, on recense 211
incidents/service requests, soit 1.15 incidents par jour.
44 entrées(s)* au total
14 incidents sur 44 entrées*
21
violations de SLA
17 entrées(s)* ouverte(s)
22 entrées(s)* clôturée(s)
1 entrées(s)* pending
4 entrées(s)* en
cours
0 entrée(s)* au statut 'unknown'
Temps moyen de résolution d'une entréé* : 70:29:11 (5582519 sec)
Temps moyen
de réaction aux entrées* : 7:36:08
* incident ou service request
Ces données constitueront notre baseline pour les
évaluations futures : amélioration de la qualité, ou le contraire. |
| 16/09/2025 - 12:24 - Tuesday |
true |
Analyse FreshService SAE du 13-03-2025 au 11-09-2025 |
Le rapport va de 13-03-2025 au 11-09-2025, soit sur une période de 183 jours. Entre ces deux dates, on recense 211
incidents/service requests, soit 1.15 incidents par jour.
Le rapport couvre la période du 13-03-2025 au
11-09-2025
167 entrées(s)* au total
112 incidents sur 167 entrées*
119 violations de SLA
20 entrées(s)*
ouverte(s)
124 entrées(s)* clôturée(s)
7 entrées(s)* pending
13 entrées(s)* en cours
3 entrée(s)* au statut
'unknown'
Temps moyen de résolution d'une entrée* : 63:40:16 (28422755 sec)
Temps moyen de réaction aux entrées* :
10:07:25
* incident ou service request
Ces données constitueront notre baseline pour les évaluations futures :
amélioration de la qualité SAE, ou le contraire. |
| 16/09/2025 - 11:53 - Tuesday |
true |
Meeting convergence PFE - SAE |
Éléments utiles de fonctionnement PFE passés à SAE:
- tenir compte des objectifs d'une itération/sprint
- tenir
compte de la charge de travail de releasing dans le backlog
Meeting avec Jérémie et Eduard |
| 15/09/2025 - 16:54 - Monday |
false |
1-2-1 Michael Keinborg |
1-2-1 = échange libre
1) La relation entre les équipes PFE et SAE va mieux (ex. convergence, outils pour tester,
...)
2) Son sentiment de SM est mitigé; oui des discussions sont en cours pour voir s'il ne conviendrait pas mieux de
prendre qqn d'autre de telle sorte qu'il puisse plus se concentrer sur son job de Dev Lead
3) Il se dit démoralisé par
l'assessment qui est conduit par qqn qui n'a pas de compétence métier spécifique. Se pose la question de savoir si
l'assessment sera fait en toute équité
4) Il pense qu'une présentation de l'assessment par le Management et Pierre
serait la bienvenue
5) Est content des résultats atteints et de la fluidité du développement / programmation
actuels
Niko-Niko: 0 (rappel échelle : -1 = négatif; 0 = neutre; 1 = positif)
il y a trop de râleurs dans l'équipe,
des gens jamais contents qui trouvent légitime qu'on leur apporte tout sur un plateau.
|
| 15/09/2025 - 15:30 - Monday |
false |
1-2-1 Gaspar Charlier |
1-2-1 = échange libre
1) Pas assez d'interactions avec SAE; pas assez synchronisé
2) Est content aujourd'hui. Se sent
évoluer et cela lui plait
3) Flou relatif concernant l'assessment; une présentation par le Management serait
souhaitable
4) Indexation de daily rate (aimerait 5% d'augmentation)
Niko-Nico : 1 (rappel échelle : -1 = négatif; 0
= neutre; +1 = positif)
Pourquoi ce sentiment ?
Pourquoi ce sentiment ?
On me permet d'être plus libre et d'avoir
plus de prises de décisions dernièrement, ce qui me plait plutôt bien.
Les process de travail sont enfin définis et
mis en place, ce qui va vers le bon.
L'équipe de testeurs nous poussent à augmenter notre qualité.
Petite bémol
pour les mises en prod qui continuent d'avoir des petits couac.
|
| 15/09/2025 - 15:00 - Monday |
false |
1-2-1 Vincent Navez |
1-2-1 = échange libre
1) Ras-le-bol général
2) Parle de partir en burnout; aurait dû être plus attentif à ce que
Pierre Bouchat lui avait dit avant son congé; n'aurait peut-être pas dû croire que le ras-le-bol exprimé avant son
congé était parti à son retour de vacances
3) Relations difficiles avec le Management
4) Est content de travailler
avec Eduard et Patrick
5) Remercie Patrick pour être capable de tenir tête au Management et protéger
l'équipe
Niko-Nico : 0 (rappel échelle : -1 = négatif; 0 = neutre; +1 = positif)
Pourquoi ce sentiment ?
Niko-Niko, je n'avais jamais entendu.
Je me mets au centre. Parce qu'il y a de chouettes choses quand même.
J'apprécie travailler avec certaines personnes.
Et je ne désespère pas que les utilisateurs auront un jour un outil
qui leur convienne pleinement.
Par contre, partir dans tous les sens, cette sensation de ne jamais avoir le temps de
finir quelque chose pleinement, aller à gauche à droite, tant de choses que je commence et puis je laisse tomber car
sur autre chose... Et quand je dois y revenir, je ne me rappelle parfois même plus ce qui avait été fait. Comme la
tête qui explose, remplie de trop de choses et ne plus savoir par où aller.
Sache que j'apprécie ton travail, ta
présence et tu fais partie de ceux avec qui j'apprécie échanger et travailler.
|
| 15/09/2025 - 14:00 - Monday |
true |
Sprint Review de PFE : Weeks 35-37 |
Sprint 2025 Weeks 35-37
• NetworkManager :
o Finir review code (jech) (regarder commits NETLINK puis ioctl pour le
contrôle des interfaces)
o Testing avec simulateur GPS (madw)
o Refaire un test en voiture (feat. autre Teltonika ?)
(didu)
• Girouettes :
o Relancer Daniel pour connaître les bus qui ont le problème des latences (alle)
o Finir la
conversoin du code SQL en object C++ (juat)
o Entamer la prochaine étape (?) (juat)
o Faire la revue de code
(jech)
• Demande SAP (Kennedy, Nathan, Ai-Ping)
o Créer la nouvelle vue dans DbConso (jech)
o Tram de Liège
o Finir
le packaging (jodu)
• PC QA
o Finir la modification Teltonika (alle)
o Release 2.2.2
o Release 25.7-2
• Bugs :
o Bug
Foreman disparition du nom de domaine
La partie "Releases" est à noter :
o Release 2.2.2
o Release 25.7-2
|
| 13/09/2025 - 17:45 - Saturday |
true |
Article Budget Équipe Agile PRODUIT sur LinkedIn |
J'ai écrit un article sur LinkedIn pour expliquer comment faire le budget d'une équipe Agile travaillant sur un
PRODUIT. Lien:
https://www.linkedin.com/posts/activity-7372650686548697088-Mbjd?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAJ9
J9ABbz7FDPynWzWFBWi-ondRTPfkAjQ
Je vais faire un document sur cette approche et j'y joindrai la feuille Excel que j'ai
également réalisée. Ceci devrait améliorer nos méthodes, procédures, et maturité pour les années à venir
(Kaizen)
Texte:
Budgeting for a Product Team: Stop Thinking “Project”
One of the most common traps in the
industry is to approach budgeting for products the same way we budget for projects. At first glance, the two may look
similar: money is spent, people are paid, and something is delivered. But the mindset could not be more different.
A
project has a clear start and end date, with a temporary team assembled to reach a defined outcome. A product, on the
other hand, has a start date but not necessarily an end. The team is long-lived, continuously evolving the product to
meet market needs. Trying to frame this with project-style financial planning is not only misleading, it wastes
time.
Budgeting for a product team is closer to budgeting for a football club:
The squad size is stable (e.g., 11
players on the field, or 11 engineers in your product team).
Individual members may change, but the capacity remains
more or less constant.
There is no ramp-up or ramp-down every few months.
And that leads to a brutal simplicity:
>
Team size × average daily rate × number of working days per year = annual budget.
That’s it. No complex
spreadsheets, no endless forecasting exercises. The calculation is so simple it feels almost cruel.
But wait—Finance
still needs more. For example, predicting cash flow means more than dividing the annual budget by 12. Real economic
activity doesn’t spread evenly across the year. Depending on your country, months vary dramatically in effective
working time.
Take Belgium as an example:
March is a full activity month (100%).
May drops to about 75%
(holidays).
July is roughly 60%.
August sinks further to 55%.
September averages 80%.
If you only divide the annual
figure by 12, Finance will face nasty surprises when payables and expenses don’t match expectations. Instead, use
national activity statistics (Statbel in Belgium is a good reference) to model monthly budgets. When you add it all up,
the total effective activity in a year isn’t 12 months—it’s closer to 9.9 months.
This adjustment transforms your
budget from a blunt annual estimate into a tool Finance can actually use. Suddenly, account payables become predictable,
cash flow management gets easier, and everyone breathes a little easier.
So next time you hear someone propose a
project-style budget for your product team, stop them in their tracks. Products are living, ongoing, and team-centered.
Budgeting for them is not rocket science—it’s multiplication, plus a dose of economic realism. |
| 13/09/2025 - 14:06 - Saturday |
true |
Budget annuel et répartition mensuelle |
Travail de répartition budgétaire mensuelle sur base des taux d'activité économique par mois en vigueur en
Belgique.
La feuille Excel est divisée en deux onglets, hypothèses (essentiellement le budget) et la répartition
mensuelle. Pour le budget de PFE et SAE, il suffira de mentionner le budget dans l'onglet hypothèses et la répartition
est calculée automatiquement. Bien entendu, cette répartition automatique est théorique et doit potentiellement être
adaptée pour rencontrer le ... réel.
Feuille "Hypothèses"
| A | B
|
|---------------|-----------|
| Budget annuel | 120000 |
Feuille "Répartition"
| Mois | Facteur | Budget
mensuel | Formule |
|------------|---------|----------------|------------------------------|
|
Janvier | 0.85 | =ROUND((B2/$B$14)*Hypothèses!$B$1, 2) | 10 303.03 € |
| Février | 0.95 |
=ROUND((B3/$B$14)*Hypothèses!$B$1, 2) | 11 515.15 € |
| Mars | 1.00 | =ROUND((B4/$B$14)*Hypothèses!$B$1, 2)
| 12 121.21 € |
| Avril | 0.90 | =ROUND((B5/$B$14)*Hypothèses!$B$1, 2) | 10 909.09 € |
| Mai | 0.75
| =ROUND((B6/$B$14)*Hypothèses!$B$1, 2) | 9 090.91 € |
| Juin | 0.95 |
=ROUND((B7/$B$14)*Hypothèses!$B$1, 2) | 11 515.15 € |
| Juillet | 0.60 | =ROUND((B8/$B$14)*Hypothèses!$B$1, 2)
| 7 272.73 € |
| Août | 0.55 | =ROUND((B9/$B$14)*Hypothèses!$B$1, 2) | 6 666.67 € |
| Septembre | 0.80
| =ROUND((B10/$B$14)*Hypothèses!$B$1, 2) | 9 696.97 € |
| Octobre | 0.95 |
=ROUND((B11/$B$14)*Hypothèses!$B$1, 2) | 11 515.15 € |
| Novembre | 0.90 | =ROUND((B12/$B$14)*Hypothèses!$B$1,
2) | 10 909.09 € |
| Décembre | 0.70 | =ROUND((B13/$B$14)*Hypothèses!$B$1, 2) | 8 484.85 € |
| TOTAL |
=SOMME(B2:B13) | =SOMME(C2:C13) | 120 000.00 € | |
| 13/09/2025 - 12:15 - Saturday |
true |
Premiers calculs budgétaires SAE 2026 |
Premières simulations pour SAE (envoi d'un feuille de calcul reprenant les hypothèses macro).
2 hypothèses
envisagées : baseline (ce quon sait de 2025) et prévisions pour 2026 basées sur variation du head count et du nb de
jours (capping) prestés sur l'année (230 à 220) tandis que le taux journalier reste fixe (ce qui n'est pas le souhait
actuel des memebres de l'équipe).
Feuilles = "Budger SAE 2026.xlsx" envoyée le 13/09/2025 |
| 13/09/2025 - 12:14 - Saturday |
true |
MTBF et MTTR sur incidents, partie SAE |
Ajout d'une note sur la manière d'interpréter le MTTR. Calcul effectué sur SAE.
Note
===
Il est à noter que les
temps enregistrés sont des temps "elapsed". Ainsi, quand un incident se produit à 18h, l'équipe ne le voit que le
lendemain. Si on imagine que la résolution de l'incident est démarrée à 9h et prend 1h à résoudre (soit 10h le
matin), alors le temps résolution sera néanmoins encodé pour 6h (18h à 24h) + 10h, soit 16h. Une semaine complète
faisant 148h et le temps de travail sur cette semaine étant de 40h, soit 5 x 8h, on en déduit que le temps moyen de
résolution des incidents est de 64h (arrondi) * 0.27 (40/148) et est donc réellement de ± 17h20. Le même calcul
devrait être réalisé sur le temps moyen de réaction aux incidents. |
| 13/09/2025 - 10:00 - Saturday |
true |
Article Incident Log sur LinkedIn |
J'ai écrit un article sur LinkedIn pour expliquer le pourquoi de l'outil "Incidents". Lien:
https://www.linkedin.com/posts/activity-7372540641190285312-W7AI?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAJ9
J9ABbz7FDPynWzWFBWi-ondRTPfkAjQ
Texte:
Examining the Incident Log: A Window into Project Quality
For any project
manager, one of the most important responsibilities is to assess the quality of what the team delivers. Beyond deadlines
and budgets, true success depends on the stability, reliability, and maintainability of the product or service. One of
the most effective—yet often underused—tools for this assessment is the incident log.
Why Focus on
Incidents?
Incidents reveal where reality diverges from expectations. Each failure, interruption, or unexpected
behavior exposes weaknesses in design, process, or execution. By systematically recording and analyzing these events,
project managers gain a direct measure of product quality and team performance over time.
Key Metrics from the Incident
Log
A naïve but valuable intuition is that if the delivered work is of high quality, the number of incidents should
decrease as the project matures. This is commonly reflected in the Mean Time Between Failures (MTBF): the longer the
intervals between incidents, the stronger the evidence that stability is improving.
Similarly, another expectation is
that as the team grows more skilled and organized, the Mean Time to Resolution (MTTR) should shorten. Quick, efficient
resolutions indicate not only technical proficiency but also effective processes, communication, and
preparedness.
Tracking these two metrics alone—MTBF and MTTR—already provides a simple yet powerful lens on quality
evolution.
Beyond MTBF and MTTR
Other dimensions can add further depth:
Incident severity: Are failures becoming less
critical over time?
Root cause distribution: Do issues stem mostly from rushed deployments, unclear requirements, or
integration points?
Detection source: Are incidents identified by the team proactively, or reported reactively by
users?
Recurrence: How often do the same types of incidents reappear?
Together, these indicators transform the
incident log into a continuous feedback system.
How AI Can Help
Artificial intelligence amplifies the value of the
incident log. By processing patterns in the data, AI can:
Highlight recurring causes across multiple projects.
Predict
risk areas before they materialize.
Generate visual dashboards to show trends in stability and responsiveness.
Provide
recommendations for preventive measures.
With such insights, the project manager moves from reactive firefighting to
proactive quality assurance.
From Raw Data to Continuous Improvement
Examining the incident log is not about blame but
about learning. Each entry, when analyzed in context, becomes a lesson. Over time, the log shows whether the team is not
only delivering faster but also delivering better.
Quality is not an abstract concept—it is written in the history of
incidents. By paying attention to this history, project managers gain an objective view of progress and a roadmap for
continuous improvement. |
| 13/09/2025 - 09:45 - Saturday |
true |
Article Logbook sur LinkedIn |
J'ai écrit un article sur LinkedIn pour expliquer le pourquoi de l'outil (d'abord appelé "Journal" et ensuite renommé
"Logbook"). Lien:
https://www.linkedin.com/posts/activity-7372536188324249600-2h-x?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAJ9
J9ABbz7FDPynWzWFBWi-ondRTPfkAjQ
Texte:
The Power of a Project Manager’s Logbook in the Age of AI
In project
management, it is often said that “what is not written down is quickly forgotten.” Yet, many project managers
underestimate the value of systematically recording the day-to-day events that shape the life of a project. A simple
logbook, consistently updated, can become a powerful tool—especially when combined with artificial intelligence.
Why
Keep a Project Logbook?
A project logbook is not a bureaucratic burden. It is a living record that captures the
highlights, turning points, and setbacks that occur throughout a project’s journey. Unlike official reports, which
tend to summarize at a high level, a logbook reflects the raw, immediate reality of project life. It helps project
managers and their teams remember not just what happened, but when and why it mattered.
What to Record?
The strength
of a logbook lies in its simplicity. Each entry does not need to be lengthy—just factual, time-stamped notes that
capture the essence of events. For example:
Failed production deployment – “On May 14th at 3:15 PM, deployment
failed due to a data export process being unexpectedly interrupted.”
Team resource issue – “During a project
review on June 2nd, it was announced that two key resources would be unavailable for several weeks, causing schedule
delays.”
Unexpected urgent request – “On July 10th, stakeholders submitted an urgent demand that had not been
anticipated, requiring immediate reprioritization.”
Positive process improvement – “On August 5th, a new request
management procedure was finalized and fully documented.”
User feedback milestone – “In September, a satisfaction
survey revealed 90% positive feedback from end users.”
These brief notes, collected over time, provide a goldmine of
insights.
How AI Adds Value
Traditionally, such a logbook would serve as a memory aid. But with AI, its usefulness
expands dramatically. By analyzing the accumulated entries, AI can:
Generate monthly or quarterly summaries that
highlight trends, bottlenecks, and recurring issues.
Detect patterns in risks, such as frequent delays linked to
resource shortages or technical dependencies.
Suggest preventive measures based on historical data, helping teams
anticipate similar challenges.
Provide visual dashboards showing correlations (e.g., production issues vs. resource
availability).
Support continuous improvement by identifying what consistently worked well.
The project manager then
enriches these AI-generated insights with context, interpretation, and strategic decisions—turning raw data into
actionable knowledge.
A Simple Habit, a Lasting Impact
Maintaining a logbook requires only a few minutes a day but
pays off exponentially. Instead of relying on memory or fragmented emails, project managers build a structured narrative
of the project’s life. Over time, this practice enhances accountability, learning, and decision-making. |
| 12/09/2025 - 18:23 - Friday |
true |
Outil d'analyse des incidents - V0 terminée |
Un outil a été réalisé qui permet de tirer des statistiques sur les incidents.
Une version 1 sera programmée pour
proposer un service qui peut retourner les données en JSON de telle sorte que tout puisse être accessible depuis une
autre app (le PSR par exemple).
L'outil sera mis sur le serveur SAE pour être utilisée par n'importe qui et de telle
sorte que l'équipe SAE puisse aussi s'emparer de l'outil et le faire évoluer.
L'outil permettra de réaliser des
stats utiles pour le CoPil |
| 12/09/2025 - 16:00 - Friday |
true |
Étude des tickets FreshService (Incidents) |
Rapport des tickets de FreshService (incidents) selon un export du 11/09/2025
SAM
===
Le rapport va de 13-03-2025 au
11-09-2025, soit sur une période de 183 jours. Entre ces deux dates, on recense 211 incidents, soit 1.15 incidents par
jour.
La notion de type de tickets n'est pas encore prise en charge (est-ce un véritable incident ?)
PFE
==
On
compte 44 incidents au total pour PFE.
44 incident(s) au total
17 incident(s) ouvert(s)
22 incident(s) clôturé(s)
1
incident(s) pending
4 incident(s) en cours
0 incident(s) au statut 'unknown'
Temps moyen de résolution d'un incident :
70:29:11 (5582519 sec)
Temps moyen de réaction aux incidents : 7:36:08
SAE
===
On compte 167 incidents au total pour
SAE.
167 incident(s) au total
20 incident(s) ouvert(s)
124 incident(s) clôturé(s)
7 incident(s) pending
13
incident(s) en cours
3 incident(s) au statut 'unknown'
Temps moyen de résolution d'un incident : 63:40:16 (28422755
sec)
Temps moyen de réaction aux incidents : 10:07:25
Note
===
Il est à noter que les temps enregistrés sont des
temps "elapsed". Ainsi, quand un incident se produit à 18h, l'équipe ne le voit que le lendemain. Si on imagine que la
résolution de l'incident est démarrée à 9h et prend 1h à résoudre (soit 10h le matin), alors le temps résolution
sera néanmoins encodé pour 6h (18h à 24h) + 10h, soit 16h. Une semaine complète faisant 148h et le temps de travail
sur cette semaine étant de 40h, soit 5 x 8h, on en déduit que le temps moyen de résolution des incidents est de 64h
(arrondi) * 0.27 (40/148) et est donc réellement de ± 17h20. Le même calcul devrait être réalisé sur le temps
moyen de réaction aux incidents. |
| 12/09/2025 - 10:30 - Friday |
true |
Meeting accès FreshService - données d'incidents |
L'idée derrière ce meeting est de savoir comment nous pouvons nous baser sur les données FreshService pour en
déduire un KPI de projet.
Par ailleurs, le nombre d'incidents, surtout lors d'événements spécifiques (exemple:
mises en production) peut nous apporter des enseignements intéressants qui nous permettraient d'améliorer la qualité
de ce qui est développé.
Rappel :
Bonjour Benoît,
Je voulais juste voir avec toi s’il y avait moyen de disposer
d’un accès à Fresh pour en extraire des données qui nous permettraient de tenir compte des incidents pour mieux
maîtriser notre qualité et juger si elle s’améliore ou pas.
Fin du mois de juillet j’avais introduit une demande
pour SAE que je te mets ici :
>>>
De : BOENS Patrick
Envoyé : jeudi 31 juillet 2025 11:27
À
: NAVEZ Vincent ; BECATTINI Jefferson ; DSE.Demande
Cc : KEINBORG Michael ; CRECIUN Eduard
Objet
: Historique des tickets Fresh Service
En tant que Chef de programme et, ultimement responsable de la qualité des
solutions SAE construites,
Je souhaite bénéficier d’un histogramme présentant l’évolution des tickets Fresh
Service (cf. similaire à image attachée),
Afin de pouvoir analyser la tendance (amélioration ou dégradation) des
solutions développées par l’équipe.
Critères d’acceptation :
1. Je peux visualiser un histogramme reflétant
l’évolution du volume de tickets Fresh Service sur différentes périodes (par mois,
trimestre…).
2. L’histogramme différencie les types/priorités de tickets (urgent, haut, moyen, bas, incident,
demande…).
3. Je peux facilement identifier les tendances (hausse ou baisse du nombre de tickets), illustrées par des
indicateurs visuels (flèches, pourcentages, couleurs…).
4. Le rapport met l’accent sur l’évolution (dynamique)
plutôt que sur le statut à un instant T.
5. Il est possible de filtrer ou d’exporter les données de l’histogramme
à des fins d’analyse complémentaire.
Le mail contient un exemple (image) d'histogramme
<<<
L’histogramme est
quelque chose que Bastien nous faisait … Évidemment, il ne faut pas faire ce travail d’histogramme (travail
remarquable de Bastien et … encore merci à lui) car nous prendrions cela en charge de notre côté pourvu que nous
ayons les données. 😉
Penses-tu cela possible, Benoît ?
Bien à toi,
Patrick
|
| 12/09/2025 - 10:11 - Friday |
true |
Monitoring |
Une réflexion est entamée depuis quelques mois sur le monitoring. Jusqu'à présent ce point, pourtant crucial pour
une application critique, n'a pas reçu l'attention qu'in devrait y consacrer et il y a peu de compréhension de
l'importance du monitoring (et alerting !) sur la composante "satbilisation" de SAE.
Ici, voici des mails qui indiquent
que le sujet est pris de manière sérieuse aujourd'hui:
De : HACHEZ David
Envoyé : jeudi 11
septembre 2025 11:22
À : PAELINCK Pierre ; BECATTINI Jefferson
; NAVEZ Vincent ; MARCOS Sara ; GOMEZ Julien
; DUVIVIER Nicolas ; NUNKOVICS Jérémy ;
BLOOM Philippe ; BOENS Patrick
Objet : RE: Souhaits en matière de
monitoring
Combien de users ?
Quelles BU sont les plus actives ?
Quand ?
A quelle fréquence ?
Quels écrans / pages
sont les plus consultés ?
Où les users rencontrent des problèmes dans leur utilisation ?
Quel est leur niveau de
frustration / satisfactions suite aux release ?
Qui sont les "champions" de l'outil ?
etc.
David Hachez
+32 476 96 98
38
Prenons un moment pour échanger
________________________________________
De : PAELINCK Pierre
Envoyé : jeudi 11 septembre 2025 11:17
À : BECATTINI Jefferson
; HACHEZ David ; NAVEZ Vincent ; MARCOS
Sara ; GOMEZ Julien ; DUVIVIER Nicolas ;
NUNKOVICS Jérémy ; BLOOM Philippe ; BOENS Patrick
Objet : RE: Souhaits en matière de monitoring
Merci déjà pour vos premières
réactions.
L'outil proprement dit est plutôt dans le scope d'Eduard. Par contre, pourriez-vous être plus factuels
(comme Vincent l'a été ci-dessous) dans vos demandes. C'est ce qui pourrait guider le choix d'un outil supportant les
besoins.
Merci.
________________________________________
De : BECATTINI Jefferson
Envoyé : jeudi 11 septembre 2025 10:47
À : HACHEZ David ;
PAELINCK Pierre ; NAVEZ Vincent ; MARCOS Sara ;
GOMEZ Julien ; DUVIVIER Nicolas ; NUNKOVICS Jérémy
; BLOOM Philippe ; BOENS Patrick
Objet :
Re: Souhaits en matière de monitoring
Je partage ce rêve… Au moins qu’on ait des informations comportementales
et du monitoring d’utilisations.. Un jour peut être 😊
Si jamais, je suis totalement dispo pour travailler sur le
sujet haha.
From: HACHEZ David
Date: Thursday, 11 September 2025 at 10:14
To: PAELINCK Pierre
, NAVEZ Vincent , MARCOS Sara , GOMEZ Julien
, DUVIVIER Nicolas , NUNKOVICS Jérémy ,
BECATTINI Jefferson , BLOOM Philippe , BOENS Patrick
Subject: RE: Souhaits en matière de monitoring
J'ai toujours rêvé d'une intégration
d'Hotjar et/ou d'un outil comme Google Analytics...
Une interface comme Intercom pourrait être utile également pour
donner, mais c'est aussi un rêve ;)))
Belle journée !
David Hachez
+32 476 96 98 38
Prenons un moment pour
échanger
________________________________________
De : PAELINCK Pierre
Envoyé : jeudi 11
septembre 2025 08:54
À : NAVEZ Vincent ; MARCOS Sara ; HACHEZ David
; GOMEZ Julien ; DUVIVIER Nicolas ; NUNKOVICS
Jérémy ; BECATTINI Jefferson ; BLOOM Philippe
; BOENS Patrick
Cc : PAELINCK Pierre
Objet
: Souhaits en matière de monitoring
Bonjour à tous,
Eduard est en train de réfléchir à la manière d'améliorer
le monitoring (y compris via les outils utilisés) proposé par SAE pour différents types d'utilisateurs.
Il m'a
demandé si nous, au sein de Service Technique, avons des souhaits à ce niveau en matière de dashboards ou d'autres
modes de reporting. Ces souhaits portent évidemment sur du monitoring de données qui pourraient vous aider dans vos
activités respectives au sein de Service Technique.
Pouvez-vous y réfléchir et me faire part de vos souhaits ?
N'hésitez pas non plus à en discuter avec Eduard.
Merci d'avance.
|
| 11/09/2025 - 21:55 - Thursday |
true |
Report automatique dans Journal |
Première version opérationnelle de l'outil de reporting dans Journal. Succès majeur en terme de Proof Of Concept
(POC). Le reporting est aussi appelable sous forme de service depuis l'outil de PSR.
Il est utile de rappeler que le
rapport est établi AUTOMATIQUEMENT sur base d'événements rassemblés dans le Journal de Bord. |
| 11/09/2025 - 10:00 - Thursday |
false |
Prise de connaissance |
Prise de connaissance avec BLAUWART Pierre |
| 10/09/2025 - 16:09 - Wednesday |
false |
SAM Central |
De : MARCOS Sara
Envoyé : lundi 8 septembre 2025 16:16
À : BOENS Patrick
; CHEVALIER Jérémie ; BECATTINI Jefferson
; NAVEZ Vincent ; HACHEZ David
Objet : Sam
Central suivi hebdo Septembre
Hello à tous,
Voici le suivi de sam central qui est attendu par chacun d'entre vous :
• Articles multiples en vue d'éduquer à la PFE // @CHEVALIER Jérémie + @NAVEZ Vincent
Est-ce que vous souhaitez
faire un nouvel article sur un nouveau thème de la PFE ? Si oui, lequel ?
• Interview de @BOENS: Attendu pour le
15/09.
• Article vis ma vie @BECATTINI Jefferson : Attendu pour le 15/09.
• Problème de mémoire réact //
@BOENS Patrick : Attendu pour le 22/09.
• Article sur les bus grisés - Statut // @CHEVALIER Jérémie
Est-ce
qu'il y a un update à faire ?
• Publication du webinaire du jour // @HACHEZ David
Merci! A la semaine prochaine
🙂
|
| 10/09/2025 - 15:15 - Wednesday |
true |
Article SAM Central avec recours à l'IA |
Un article est paru sur SAM Central dans lequel il apparaît que l'équipe envisagerait d'intégrer un chatBot. Ceci est
apparu dans l'article
"https://letecinside.sharepoint.com/sites/SAMCentral/SitePages/Replay-du-webinaire-sam-du-8-septembre-2025.aspx"
Cette
annonce est parue exagérée à notre Management et aussi sponsor (Christian Pochet) qui a demandé à Nicolas Forget de
tempérer la fougue affichée.
Voici le contenu des mails :
De : FORGET Nicolas
Envoyé :
mercredi 10 septembre 2025 15:14
À : HACHEZ David ; BOENS Patrick ;
BLAUWART Pierre ; PAELINCK Pierre
Cc : POCHET Christian
Objet : TR: Sam central
Bonjour,
J’avais demandé suite aux dernières publications
d’avoir ma validation sur les publications qui étaient erronées (cf la validation du nouveau bloc com). Je constate
que ce n’est pas le cas. Serait-il possible d’y remédier ?
D’autre part, j’aimerais une communication plus
modeste et en phase avec ce que nous réalisons effectivement. Parler de mise en place d’un chatbot alors que nous ne
sommes pas encore capable de valider des releases à plus de trois mois me semble fort ambitieux ! Merci d’en tenir
compte lors de vos prochaines communications. Rien de ce qui n’a pas été validé et planifié ne doit être
communiqué.
Bon après-midi,
Nicolas
Responsable solutions métier
De : POCHET Christian
Envoyé : mardi 9 septembre 2025 14:44
À : FORGET Nicolas
Objet
: Sam central
Hello,
Il faudrait se calmer sur les effets d'annonces. Ici, parler d'IA va nous retomber dessus.
"Une aide contextuelle est envisagée : un bouton d’aide dans sam qui redirigerait vers la documentation spécifique
au module utilisé. À plus long terme, l’équipe souhaite intégrer une aide intelligente via un chatbot basé sur
l’IA (type Copilot), capable de répondre aux questions des utilisateurs en temps réel, en s’appuyant sur la
documentation"
Est-ce que tu peux faire passer le mot ?
Pas de communication sur l'ia sans validation de la direction
IT.
Merci,
Christian
---------------------------
Il faut retenir de ces remarques que les publications dans SAM
Central doivent être validées par Nicolas Forget |
| 10/09/2025 - 14:00 - Wednesday |
false |
Traductions PFE et SAE |
Intégration nouvelle demande (Cycle #4) – Décision
Participants : Jefferson Becattini, Patrick Boens, Vincent Navez,
Eduard Creciun
Contexte :
Réunion pour évaluer la faisabilité d’intégrer une nouvelle demande (traduction des
arrêts) dans le planning du Cycle #4 (SAE/PFE).
Décision clé
❌ Non intégrable en l’état :
La demande n’a
pas été validée pour le Sprint 85 (Cycle #4).
Manque de clarté sur le périmètre et les dépendances (ex. : impact
sur les fourgons, descriptions réseau).
Actions immédiates
Eduard Creciun : Envoie un mail récapitulatif avec les
éléments partagés en amont (discussions initiales).
Clôture le sujet pour cette itération.
Vincent Navez : Relance
Alexandre Harpigny pour clarifier :
- Le périmètre exact (quels arrêts ? quels systèmes impactés ?).
- La
priorité (pour un éventuel report en Cycle #5).
Prochaines étapes
Si la demande est prioritaire : Revoir
l’intégration dès le Cycle #1 de 2026 (après validation des dépendances).
Sinon :
Classer en backlog avec un
label "À clarifier".
En bref :
On ne prend pas la demande en Cycle #4. Vincent relance Alexandre pour préciser le
besoin, et on reverra l’intégration plus tard si nécessaire.
----------------------------
Notes d'Eduard
Creciun:
Coté SAE :
• Afficher les arrets traduits sur SAE
o Import des traductions des arrêts (via GTFS ?, via
OIG ?)
o Service matériel, Arrêts, Carto temps réel, Carto historique, Alertes, Logs,
o Doit-on prendre en compte
la langue de l'utilisateur SAE (FR) ou de la langue principale donnée par Hastus (NL) ?
o Quid des exports vers ELK
?
• Redescendre les traductions des arrêts vers les PFE ?
o Suggestion de Jérémie : intégrer la traduction des
arrêts dans chacun des voyages descendu sur les PFE ==> adapter le script créant les fichiers ODM
o Suggestion Eduard
: créer un/plusieurs fichier(s) de référence avec les traductions des arrêts à descendre
• PFE :
o Afficher les
arrêts et leurs traductions sur la PFE
• Quid Girouette ?
• Quid bandeaux lumineux ?
|
| 10/09/2025 - 13:30 - Wednesday |
true |
Préparation budget 2026 |
Objet : CR – Réunion budgétaire 2026 (Préparation initiale pour SAE) – Actions & Décisions
Bonjour
Eduard,
Ci-dessous le compte-rendu structuré de notre échange de ce jour concernant les premiers éléments du budget
2026, avec les décisions prises et les actions à mener d’ici notre prochaine réunion.
1. Contexte &
Objectifs
Participants : Eduard Creciun (Chef de Service), Patrick Boens (Chef Programme)
Objet : Établir les bases du
budget 2026 (méthodologie, données clés, répartition Opex/Capex).
2. Points clés discutés
🔹 Méthodologie
budgétaire
• Approche simplifiée :
o Budget calculé sur un noyau d’équipe stable (variations limitées :
arrivées/départs ponctuels).
o Formule : Budget = Nombre de personnes × Jours prestés (220–240/an) × Taux
journalier moyen
o Exemple de calcul des jours : 365 jours – 104 (weekends) – 11 (congés légaux) – 20 (vacances)
– 10 (autres) ≈ 220 jours/an.
• Répartition Opex/Capex :
o Proposition initiale : 20% Opex / 80% Capex (éviter
un déséquilibre type "80% Opex" comme chez ING, limitant l’innovation).
o À valider : Pas de décision finale, mais
besoin de clarifier cette répartition.
🔹 Ressources humaines & Coûts
• Stabilité de l’équipe :
o Privilégier
un noyau fixe pour éviter les coûts cachés (formation, perte de productivité).
o Risque : Départs anticipés si le
budget 2026 est trop réduit pour 2027 (ex. : passage de 2,1M€ à 600k€).
• Données à collecter :
o Taille de
l’équipe : Lister les membres actuels (inclure consultants comme Nicolas Duvivier/Jérémy Nunkowics (voir si on a
d’autres personnes) même s’ils dépendent d’autres budgets – cfr. Pierre Paelinck).
o Historique des départs :
Vérifier les dates (ex. : David Godefroid, Dominique, Guy, autre ?) pour ajuster les mois non consommés.
o Taux
journalier moyen : À confirmer avec Nicolas Forget (attention aux profils spécifiques : architectes, experts
sécurité).
• Licences & Outils :
o Recenser les coûts récurrents (ex. : PHP Storm pour les devs, licence outil
pour Release Notes, …).
o Risque : Oublis de renouvellement → outils désactivés (ex. : cas FGTB avec les
AS/400).
🔹 Marges & Flexibilité
• Tolérance : ±5% par rapport au budget (marge totale de 10%).
• Événements
exceptionnels (incendies, perturbations, …) : Non intégrés au budget initial.
• Indexation des tarifs :
o Les
consultants doivent négocier eux-mêmes via leur agence (le client ne gère pas ces ajustements). Le budget sera
calculé en fonction du tarif journalier moyen en vigueur aujourd’hui (10/09/2025)
3. Décisions &
Actions
Action Responsable Échéance Détails
1. Finaliser la taille de l’équipe Eduard 17/09/2025 Lister les
membres actuels + historiques des départs (dates exactes).
2. Obtenir le taux journalier moyen Eduard + Nicolas
Forget 17/09/2025 Confirmer le coût moyen des consultants (attention aux profils hors norme).
3. Estimer les jours
prestés Patrick 17/09/2025 Fixer un nombre moyen (ex. : 220 jours/an) et vérifier les contrats.
4. Recenser les coûts
Opex Eduard 17/09/2025 Lister licences (PHP Storm, etc.) et outils récurrents + échéances.
5. Calculer le budget
initial Patrick 17/09/2025 Appliquer la formule et comparer avec la prévision budgétaire de 2026 établie par NiFo
(±2,1M€).
6. Proposer un report budgétaire (si surplus) Patrick + Nicolas Après calcul Si besoin < 2,1M€,
demander un carry-over vers 2027.
7. Valider la répartition Opex/Capex Eduard + Patrick 17/09/2025 Décider du ratio
(ex. : 20/80) en fonction des priorités.
4. Prochaines étapes
• Réunion de suivi : Semaine prochaine (17/09/2025)
pour :
o Valider les données (équipe, taux, jours).
o Discuter du budget initial et des ajustements
nécessaires.
• Préparatifs :
o Eduard : Enverra les données actualisées (équipe, coûts licences).
o Patrick :
Vérifier les dates de départ de certaines ressources et différence avec les nouvelles arrivées pour voir si nous
disposons d’un partie budgétaire supplémentaire en 2025.
5. Risques à anticiper
• Sous-estimation des coûts :
Profils spécifiques ou jours prestés > 240/an.
• Turnover : Départs si le budget 2026 est perçu comme
instable.
• Oublis de renouvellements : Licences ou contrats non suivis (ex. : PHP Storm, AS/400, …).
6. Message
clé
"Nous partons des besoins réels (équipe, jours, tarifs) pour construire le budget, puis nous l’ajustons avec
les contraintes. L’objectif est d’éviter les surprises et de garantir la stabilité de l’équipe."
Prochaine
réunion : 17/09/2025 pour faire un nouveau point
Bien à toi
Patrick |
| 10/09/2025 - 08:35 - Wednesday |
false |
Adaptation du GO/No GO |
Ajout du nom des personnes participant à une mise en production dans le document Go/NO Go en vue d'améliorer la
préparation des mises en production. Cette modification fait suite au meeting de "post-mortem" ayant été organisé
après les difficultés de mise en production du 02/09/2025. Autre notion : le nomination d'un Incident Manager
"éphémère" (car rôle inexistant au TEC) pour la gestion de la communication entourant la mise en production et plus
particulièrement quand un incident survient. |
| 09/09/2025 - 17:00 - Tuesday |
true |
Post-mortem Mise en Production du 20250902 |
Analyse de la dernière release et discussion sur les pratiques DevOps
Ordre du jour de la réunion:
1. Retour sur les
problèmes rencontrés lors de la dernière release SAE (Statham)
2. Discussion sur l'intégration des pratiques DevOps
et l'automatisation du pipeline de déploiement
3. Discussion autour de la communication en cas d'incident
4. Analyse du
processus de rollback actuel et des améliorations possibles
5. Suivi de la traçabilité des actions liées aux
problèmes de mise en production
Contenu de la réunion:
• Discussion sur les pratiques de release et l'avis d'un
collègue: Un participant relate une discussion avec un collègue qui prône des releases séparées pour les
corrections de bugs et les nouvelles fonctionnalités, une pratique jugée obsolète. Il est mentionné l'existence d'un
change Advisory Board pour les changements importants. Les participants conviennent de ce que cela ne s'appliquera pas
à SAE dans l'état actuel
• Intégration DevOps et automatisation: L'arrivée d'un ingénieur DevOps est soulignée,
avec pour objectif d'automatiser le pipeline de déploiement, potentiellement jusqu'à la mise en production après
validation des tests (y compris les tests d'acceptance). L'importance des rollbacks et de la prévention des
interruptions de service est évoquée.
• Un post-mortem a déjà été organisé la semaine précédente avec
l'ensemble de l'équipe. Ce post-mortem a été pris en charge par Jérémy Nunkovic.
• Incident et communication:
Benoît Tielmance a interpellé un participant sur un problème de mise en production. Le participant n'étant pas
informé, il a redirigé Benoit vers Jérémy. Il est constaté un manque de communication et une nécessité
d'améliorer la gestion des incidents.
• La qualité des données utilisées par SAE est soulevée, notamment la
possibilité de mettre en place des scripts pour vérifier leur validité. Il est précisé que le script correctif
appliqué pour la mise en prod du 02/09/2025 a été créé par les développeurs, pas par les testeurs. La question de
la nécessité de créer des scripts de test spécifiques par les testeurs est posée. La réponse est que, bien que
d'autres tests auraient pu être effectués, les tests automatiques et le taux de couverture sont prioritaires, et que
le problème venait de données externes incorrectes.
• Le processus de rollback actuel est jugé insuffisant. Bien
qu'il existe une procédure manuelle, elle est considérée aussi risquée que la mise en production. Il est évoqué la
complexité de la gestion des données lors d'un rollback, notamment dans le contexte de bases de données volumineuses.
L'idéal serait un système de snapshot différentiel avec application de partitions au niveau des tables les plus
lourdes ce qui réduirait considérablement le volume des données à remettre en place. Ce mécanisme peut être
complété par la tenue en compte du journaling des bases de données, qui permettrait ainsi de reconstituer les
données mises à jour pendant la mise en production. L'équipe a déjà effectué des rollbacks par le passé ce qui
indique qu'une procédure de rollback existe bel et bien. La question des critères de déclenchement d'un rollback est
abordée. La question des rollbacks de données est affaire délicate et cette question s'est invitée régulièrement
lors des interviews d'engagement d'un spécialiste DevOps. Personne, dans les interviews, n'a finalement proposé de
solution satisfaisante ce qui indique le côté particulièrement épineux de la question.
• Traçabilité des
actions: Le dernier point concerne la traçabilité des actions liées aux problèmes de mise en production. Il est
important que les incidents soient bien documentés et visibles, et pas seulement cachés dans un backlog. Des tickets
ont été créés pour corriger les problèmes et améliorer la documentation technique. La traçabilité n'a d'autre
objectif que de pouvoir s'appuyer sur des constats objectifs en vue d'une amélioration permanente.
• Proposition
d'amendement du document Go/No Go pour intégrer le nom des personnes prévues pour la MeP, pour éventuellement
intervention si incident, et le nom d'un Incident Manager qui serait en charge de la gestion de l'incident et de toute
la communication entourant la mise en production.
Conclusions:
L'équipe doit travailler sur l'amélioration de la
communication lors des incidents, explorer des solutions pour la gestion des données lors des rollbacks
(potentiellement avec l'aide du nouvel ingénieur DevOps), et s'assurer de la traçabilité des actions liées aux
problèmes de mise en production.
Prochaines étapes à planifier:
1. Intégrer le nouvel ingénieur DevOps dans la
réflexion sur l'automatisation et l'amélioration du pipeline de déploiement.
2. Explorer des solutions pour
améliorer la gestion des données lors des rollbacks, en particulier un système de snapshot différentiel.
3. Définir
clairement les critères de déclenchement d'un rollback et s'assurer qu'ils sont bien compris par l'équipe.
4.
Améliorer la communication lors des incidents et s'assurer que les actions correctives sont bien documentées et
visibles.
Affaires en attente de traitement et affaires laissées pour compte:
1. Définition d'une architecture de
données permettant des rollbacks plus efficaces.
|
| 09/09/2025 - 16:00 - Tuesday |
true |
Présentation Management pour PO |
Nouveau document PowerPoint qui devrait améliorer le fonctionnement du département en général et du programme en
particulier.
De : PAELINCK Pierre
Envoyé : mardi 9 septembre 2025 15:51
À : BOENS Patrick
Cc : PAELINCK Pierre
Objet : Présentation PM/PO à
Christian/Nicolas
Patrick,
Ci-joint le doc avec quelques slides de plus pour faire comprendre à Christian et Nicolas
en quoi ils peuvent continuer à faire leur management asynchrone par rapport à la cadence agile (mais en leur faisant
comprendre qu'ils n'ont pas 'tous' les droits et qu'ils ont certaines obligations pour que cela marche).
On peut en
discuter par Teams demain.
Merci.
|
| 09/09/2025 - 16:00 - Tuesday |
true |
Production PFE V2 |
De : BOENS Patrick
Envoyé : mercredi 10 septembre 2025 10:21
À : LEFEBVRE Alexis ; PAELINCK
Pierre ; DUCHATEAU Dimitri ; FORGET Nicolas
; POCHET Christian
Objet : Situation assemblage Bloc Comm dans
Production PFE V2
Bonjour,
Alexandre continue à avancer selon le rythme anticipé au départ.
Alexandre n’est pas
bloqué.
• Rythme journalier : 4 HMI/jour
• Réalisé : 110 HMI assemblées et emballées
À suivre : état des
commandes pour ne pas se trouver sans travail pour Alexandre
Bàv,
Patrick
|
| 09/09/2025 - 14:50 - Tuesday |
true |
Product Owner |
Nouvelle proposition de définition de Product Owner dans le cas d'une organisation hybride. Un document est disponible
:
https://letecinside.sharepoint.com/:w:/r/sites/TEAMS-P027-SAEPFE-RPSEDSE/Documents%20partages/RPSE%20%20@%20DSE/70.%20Bi
blioth%C3%A8que/20.%20Travail/Product%20Owner.docx?d=w792da877d11540d882c588e15c461750&csf=1&web=1&e=Y41hzu
Ce
document est aussi complété par une définition du rôle de Chef de projet Waterfall et Agile (peut-être à adapter):
https://letecinside.sharepoint.com/:w:/r/sites/TEAMS-P027-SAEPFE-RPSEDSE/Documents%20partages/RPSE%20%20@%20DSE/70.%20Bi
blioth%C3%A8que/20.%20Travail/Chef%20de%20Projet%20Waterfall%20et%20Agile.docx?d=wd4c08b5127f2410c8fed8eb146361b15&csf=1
&web=1&e=06mG5w |
| 09/09/2025 - 14:00 - Tuesday |
true |
Plan de releases - Horaire SAE |
Nouveau plan de releases reçu de la part d'Eduard suite à meeting de statut (voir mail ci-dessous)
De : CRECIUN
Eduard
Envoyé : mardi 9 septembre 2025 14:00
À : NAVEZ Vincent ;
BOENS Patrick ; BECATTINI Jefferson
Cc : KEINBORG Michael
Objet : Plan de releases pour SAE revu
Salut,
Release GO/NO GO MeP Contenu SAM
présente Client
Atlas 24/07/2025 29/07/2025 • Phénix (stabilisation = websockets, appels FE BE standardisés,
surconsommation mémoire, …)
• Pause sanitaire
• Liste MoSCoW pour Liège-Verviers 11/08/2025
Ardentia
(ceci
n’est pas une release) Entre le 04/08/2025 et le 14/08/2025 Entre le 04/08/2025 et le 14/08/2025 • Bascule LV Mois
d’octobre
Statham 13/08/2025 -> 21/08/2025 19/08/2025 -> 02/09/2025 • Transporteurs (phase 1 : carto temps réel,
carto historique, gestion utilisateurs transporteurs, accès de l’extérieur)
• Bugs (connexion, bus grisés, msg
programmés inactif)
• Cartographie historique améliorée
(7 minutes -> 10 secondes) 15/09/2025
Radio Charleroi
(Cycle 4) Entre le 15/09/2025 et le 22/09/2025
25/09/2025 Entre le 15/09/2025 et le 22/09/2025
07/10/2025
• Intégration Radio Charleroi dans SAM-SAE
• Décommissionnement Partiel de CCS (copil 9 octobre)
• Bandeaux
lumineux (S99)
• Envoi de SMS à un groupe de personnes 20/10/2025 BU de Charleroi
CCS (cycle
4) TBD TBD • Migration numéro dispatch (dépend de corresp, et G4s)
• Décommissionnement CCS (copil 9 octobre)
• Ack (lié au numéro dispatch)
• Téléphonie (lié au numéro dispatch) --> 30,31,32,33,34
• [New] Intégrer
les détresses sur G4s
• [New] Correspondances Hastus ? Copil prévu 9 Octobre TBD Namur, Luxembourg,
Brabant
(+ gain pour les autres BU)
Géoloc (cycle 4) TBD TBD Décommissionnement Géoloc :
• Suppression
fonctionnalités : ack, téléphonie GDS Adapter GDS ? Equipe PFE le prend ?
• Couper accès à l’interface
web
TBD Hainaut, Liège, Charleroi,
Jason (cycle 4) Fin Novembre Mi-Décembre Transporteurs Phase 2 :
• Suppression de voyages par les transporteurs
• Visuel des modules en lecture permettant la suppression de
voyages
Fin Décembre SERES
Agent 007 (cycle 4) Début Décembre Mi-Décembre Intégration module Service Agent dans
SAE :
• Nouveau module pour la lecture de la journée d’un agent
• Suppression de voyages liés à un service
agent Fin Décembre Toute BU
Bav,
Eduard
|
| 09/09/2025 - 09:00 - Tuesday |
true |
Demande Traductions |
Nouvelle demande qui semble venir de Benoit Vanderputten (Carine Lheureux) concernant la traduction de messages pour que
ceux-ci s'affichent dans la langue de la région dans laquelle passe le bus (par exemple en allemand).
Meeting
convoqué par Alexis : invités = Eduard et Patrick
Dans l'état actuel la demande ne peut pas être prise en compte
sans un arbitrage des priorités.
Question : pourquoi ViNa n'a pas été invité au meeting alors qu'il est le PO de
SAE ? |
| 08/09/2025 - 15:00 - Monday |
false |
|
Meeting sur les budgets avec Nicolas
1. Budget et Structure des Fichiers Excel
• Le fichier Excel utilisé comporte
deux onglets principaux : “Ressources” (internes) et “Coûts” (externes).
• Les ressources internes sont
saisies par profil (employé, cadre, etc.), et le fichier calcule automatiquement leur coût. On ne modifie pas
certaines cellules “secrètes” qui calculent pour plusieurs internes.
• Les coûts des ressources externes ont
été agrégés par code budgétaire pour simplifier la présentation.
• Certains tableaux croisés présentés en
comité contenaient des incohérences (absence de formules de somme, erreurs de consolidation). Depuis, des corrections
ont été apportées pour fiabiliser les totaux.
2. Réconciliation budgétaire et suivi historique
• La finance,
représentée par Isabelle et Nicolas Marchal, réalisait des réconciliations avec d’anciens tableaux Excel, mais il
n’y avait pas toujours de formules ni d’automatisme : vigilance requise.
• Il a parfois fallu intervenir pour
corriger les montants “en live” lors des réunions, surtout quand le budget était sous-exécuté par rapport aux
prévisions.
• Les postes budgétaires sont répartis par année, et les hypothèses ou ajustements sont explicités
uniquement dans certaines formules corrigées.
3. Problèmes identifiés et gestion du RUN
• Des erreurs de prévision
dites “première erreur” : le “RUN” n’est pas budgété correctement, bien que l’équipe le réalise en
interne (coût absent du budget ; “coût zéro” en apparence pour les internes, mais c’est fictif).
• Dans le
business case initial, la répartition entre investissement et “run” (exploitation/maintenance) aurait dû être
chiffrée : ce n’est pas fait pour ce projet.
• Le nombre de personnes requises pour le run reste variable et
difficile à budgéter, avec des pics à certains moments (maintenance, support utilisateurs, demandes
ponctuelles).
• Le suivi budgétaire sur les prestataires ou les sous-traitants (consultants, matériel,…) est plus
formalisé que pour les charges internes.
4. Suivi de la consommation, commandes et facturation
• La réception du
matériel est suivie : commande, livraison, facturation, validation dans SAP. Les contrôles de conformité (nombre,
prix unitaire, tolérances) sont automatisés ou manuels selon la nature des postes (matériel/prestation).
• Les
commandes sur prestations (consulting, management) sont validées par un responsable de projet (souvent Vincent Cordy,
sinon un remplaçant identifié).
• Pour les coûts de maintenance ou “run”, ces éléments restent sous-évalués
ou non chiffrés.
• Contrôle des factures : système de tolérance (en pourcentage/valeur absolue) pour éviter de
bloquer des factures pour de petits écarts.
5. Organisation du suivi budgétaire
• Suivi mensuel recommandé, mais
confronté à des délais de consolidation comptable (décalage permanent d’un ou deux mois entre la prestation et la
mise à jour effective du budget).
• Recommandation de réaliser un “statut budgétaire” régulier pour suivre
l’état d’exécution et anticiper les dérives.
• Demande explicite que les référents projet soient responsables
de l’actualisation et du suivi, avec reporting partagé lors des réunions de coordination.
6. Planification et
prévision pour les exercices suivants
• L’exercice budgétaire pour l’année suivante doit être réalisé à
l’automne (septembre/octobre).
• Questionnements sur la répartition entre investissement (capex) et exploitation
(opex/run).
• Propositions d’amélioration : rééquilibrer les budgets par année, mieux prendre en compte le
“run”, réfléchir à la ventilation budgétaire.
• Les justifications de besoin doivent être argumentées ;
toute évolution nécessite que l’équipe explique ses besoins et propose des arbitrages.
7. Cas spécifiques et
montants discutés
• Certains montants concrètement cités : matériel (~13 000 000€), consultants (variable
sur plusieurs années de 400 000€ à 1 000 000€/an selon l’année/projets).
• Suivi spécifique des
budgets transversaux (architecture, test, etc.) ventilés entre plusieurs lignes.
• Cas Proximus / box COM : le
coût unitaire renseigné (1 480€ à affiner), l’offre n’étant pas encore reçue, ce sont des hypothèses de
travail.
• Prise en compte de dépassements, ajustements, et retours d’expérience sur des dépenses effectives
versus plans initiaux.
8. Gouvernance et responsabilité
• Le budget projet relève de la responsabilité du Chef de
projet/Programme : préparation, explication, arbitrage.
• La validation des factures est partagée selon la nature
des dépenses et la disponibilité des responsables.
• Toutes les évolutions (demande supplémentaire, changement de
périmètre, démarrage/arrêt d’activités) doivent être formalisées, avec suivi et validation.
Bien à
toi,
Patrick
PS : toi tu es responsable pour l’élaboration du budget, moi je suis responsable pour vérifier, mois
après mois, que le budget établi est respecté. Cela te va ?
|
| 08/09/2025 - 13:00 - Monday |
false |
|
Suivi des commandes, gestion de la production et allocation des tâches : projet PFE.
1. Statut des commandes MC 100
et des composants Telltonica LMC.
2. Clarification des responsabilités entre les équipes internes et Proximus.
3.
Gestion des petites commandes et rôle de Gérald.
4. Soutien à Alexandre pour le montage des HMI.
5. Production des
PFEV 2 et R&D avec Proximus.
Agenda:
======
• Commandes et Matériel:
• Il y a un problème avec la commande des
MC 100 et des composants Teltonica. Les bons de commande existent mais il semble y avoir un retard de livraison. Le
planning initial est compromis (simulations.xlsx)
• Les composants Teltonica ont été reçus.
• Responsabilités
Proximus:
• Une clarification est nécessaire concernant les responsabilités de Proximus, notamment sur l'assemblage
des 440 avec PCB. La possibilité d'acheter l'ensemble chez Proximus est envisagée.
• La production du PCB pourrait
être sous-traitée à Proximus, mais l'assemblage final pourrait rester en interne si Proximus ne peut pas le faire
assez rapidement.
• Petites Commandes:
• Gérald s'est occupé des gros marchés pour les 400 prochaines
commandes.
• La gestion des petites commandes n'est pas prioritaire pour le moment. Patrick propose son aide si
besoin pour ces petites commandes, expliquant la procédure à suivre (3 offres, etc.).
• Soutien à Alexandre:
• Alexandre a peut-être besoin d'aide en raison de retards et d'absences. L'idée d'un monteur supplémentaire,
initialement prévue pour octobre, n'a pas été retenue.
• Alexandre suit la production des HMI via un fichier
Excel partagé.
• Si la charge de travail devient trop importante, un soutien supplémentaire sera envisagé.
•
Production PFEV 2 et R&D:
• Il est préférable que Proximus produise les MC 100.
• Le design du PCB des
PFEV 1, réalisé en collaboration avec Proximus (ou ses sous-traitants), ne donne pas entière satisfaction aux BU, car
le concepteur n'aurait pas une grande expérience dans le domaine automobile.
Conclusions:
===========
•
Clarification des responsabilités est nécessaire.
• Un suivi régulier est indispensable pour éviter les
retards.
• L'aide de Patrick est proposée pour les petites commandes.
• Le besoin d'un soutien à Alexandre sera
réévalué.
• La production des MC100 sera confiée à Proximus.
Prochaines étapes à
planifier:
=============================
1. Identifier clairement les responsabilités de chacun (interne et
Proximus).
2. Relancer le fournisseur pour les câbles manquants.
3. Evaluer la charge de travail d'Alexandre.
4. Suivre
de près l'avancement de la production des PFEV 2 avec Proximus.
Affaires en attente de traitement et affaires laissées
pour compte:
1. Décider de la stratégie à adopter pour la production des PCB des PFEV 1 compte tenu des retours des
BU.
2. Clarifier le rôle de Pierre concernant les commandes.
Transcription
=============
Pas commandé le MC 100
enfin.Mais pour moi oui je vois encore les 2 bons de commande.Voilà.Je vois le bon de commande 2 Laurence.Non c'est
Xavier qui m'a passé 2 bons de commande qui lui venait de Laurence.Les 2 bandes commandes étant telltonica LMC je suis
désolé de pas pouvoir.Pour répondre précisément non mais c'est c.Les daltonica on les a reçus c'est sur MC 3 il
devait encore faire un partenariat et tout ça pour moi. Ce qui m'importe enfin.Tout le planning qu'on a fait.Tom.Oui
là.Tout ce planning tombe.Parce que effectivement on n'a pas le Matos y compris le MC 100 avec le PCB et cetera. Donc
tout ça tombe il va falloir qu'on.Qu'on replonge dessus pour voir.OK mais alors surtout il y a pour moi il y a une
espèce de confusion et c'est peut être juste moi c'est quoi s'occupe de quoi ?Parce que si on me dit Ben Oui Ben
maintenant nous on c'est proximus qui va s'occuper ?Y compris ici pour les 440 de l'assemblage avec le PCB alors que
j'avais pas l'impression que ça c'était enfin c'est pas du début on voulait pas. Et puis finalement le PCB devenant
plus compliqué.Et sous traités à Proximus.Avec la avec le sous-traitant plus machin.Autant tout acheter chez
proximus. C'est vrai qu'on a toujours une porte de sortie ici. Jamais.Eux ne savent pas assembler assez vite mais le PCV
on va devoir le faire produire alors nous même oui mais non OK il y a des câbles que j'ai pas envie qu'on produise
nous même. Je ne vais pas oui oui non mais ça je vais pas changer la façon de faire mais alors je dois suivre.À la
culotte.Le projet 4G Next G enfin ce que je fais déjà je dois dire que parfois j'ai des incompréhensions mais.Ne
fût-ce que pour pouvoir.M'occuper de ce de la production des PFEV 2OK alors maintenant.Et je vais terminer
là-dessus.Tu me dis oui je m'occupe de ça des petites commandes et cetera sinon.Apparemment c'est Gérald qui place
ses commandes et lui Gérald il est occupé un il a fait les gros marchés pour les 400 prochaines.D'accord il a mis en
place les marchés pour les gros les gros montants pour les 400 prochaines qu'on doit faire.Mais je me souviens
d'un.Très anciens meetings de crise que l'on a eu.Où on disait.Que il allait de voir aussi s'occuper de tous les
petits marchés. Ouais mais là il a lancé ce qui était prioritaire c'est à dire les gros marchés parce que il y a
des signatures au CA au machin et tout ça. Donc il a annoncé les plus gros donc ça.Je comprends tout à fait la
démarche oui oui.Mais et alors donc tous ces petits marchés c'est toi qui t'en occupes ou quoi ?Ah Ben moi j'ai pas le
temps d'acheter les petits trucs pour le moment.Et c'est pas urgent selon toi ?Non parce que c'est des trucs qui vont
plus vite mais moi j'ai pas le j'ai pas le temps maintenant de.De le faire bon OK.Si jamais quelqu'un te demande
éventuellement de le faire.Tu m'en parles et je le ferai à ta place.Tu m'expliques comment ça se fait ? Parce que
souvent 3 offres et tout ça. Et puis il y a des choses tu peux pas acheter maintenant parce que ça va dépendre de qui
va gagner. Oui oui je suis là d'accord mais donc ?Quand on te demande de le faire OK ?Tu viens m'expliquer tu me dis
Patrick ?Voilà tu veux bien t'en occuper et je m'en occuperai je voilà. Ce qui me permet d'ailleurs de revenir sur le
sujet.Où tu me disais je suis un quand même un peu noyé parce que Pierre il me suscite quand même beaucoup et cetera
et donc j'ai mentionné effectivement le risque.D'avoir Xavier mais aussi Alexandre qui sont.Fragile Xavier n'est pas
n'est pas en cours de retour viendra.Je pense et c'est bien s'il revient ce sera même pas à temps plein.Et alors
Alexandre voilà donc en fait j'ai mentionné ce risque et j'ai dit.Je suggère que nous.Cherchions.Une autre personne
tu m'avais d'ailleurs dit à ce moment-là.Oui faites quand même très attention que lui Alexandre ne prenne pas ça
comme étant une piste de remplacement de lui.Il faut pas prendre quelqu'un maintenant parce que.Je pense pas que c'est
maintenant maintenant mais quand il va pouvoir commencer avec vous soir et ça tu sais plus ou moins quand. Mais non
parce que le fournisseur il y a plusieurs lots.Mais on risque qu'on s'acque sur le premier lot.Qui a les câbles qu'on
fournit ? Mais qui enfin ?Il y a des câbles les câbles imprimantes tout ça ont été fournis donc ça il s'est
assemblé tous les HMI bien pas de problème.Mais y a certains câblages qui j'ai été dans un autre lot y avait pas
bien compris que c'était prioritaire ce lot-là.Et du coup enfin de toute façon il nous faut tous les cas mais le
fournisseur tarde un petit peu donc il faut le relancer régulièrement.Voilà.Voilà dim.Mon message par rapport à ça
c'est que je demanderai aux achats de choix.Oui et si ?Tu as besoin d'aide ? Tu viens chez moi ? OK. Mais je pense
qu'Alexandre a pris un peu de retard. Il a eu aussi des absences. Oui et c'était pas exclu un moment de lui prendre un
coup de main.Quoi il n'a ? Au départ il était prévu de prendre pour le mois d'octobre.Une 2e un 2e ?Qu'on appelait à
ce moment un monteur. OK ce à quoi Christian a dit non on va pas le faire on va juger sur PS si oui ou non il le faut
et cetera. Donc en fait ça en est resté parce que là maintenant je crois qu'il y a peut être 80 chami qu'il a monté
un truc comme ça je vais aller voir aujourd'hui ou demain OK ? Lui il a tout consigné tout ce qu'il a.Produit et la il
sait te dire combien il en a fait. Il a un fichier Excel qui est parfait qui est partagé où il met tout ça ? Eh Ben
écoute dim alors j'ai. Mais il y a eu un peu de retard avec ses ses absences.Bah là maintenant c'est
reparti.D'ailleurs je vais aller lui chercher des cartons tantôt parce que on emballe encore des trucs et voilà.Dans
les si t'as besoin d'un coup de main. Ah sauf c'est la prévision va être compliquée. Je suis rempli de mains. Mais
voilà OK là il est parti.Ils font sur les HMI de toute façon les poussoirs il s'est pas fait grand chose parce qu'on
avait pas les télétomica.Et on n'a pas encore tous les câ.Et puis ça va un peu d'avance mais.Voilà OK j'en sais
assez je prends note de ça. Coordonnées avec Pierre.C'est ouais après maintenant je pense que c'est sur la bonne voie
mais.Mais pour moi la NC 100 il vaut mieux les faire produire par proximus.Qui t'a dit livré plus tard ?Oui mais j'ai
pas de souci avec ça c'est juste de.De pouvoir gérer le bazar et cetera quoi.Parce que je t'avoue que j'ai discuté
des.Ben avec Pierre et en ce moment j'ai dit mais pierre ?Les commandes puisque tu prenais la place de Benoît Castres
les commandes tu t occupes aussi des miennes.Pour ici.OK Ben non je nous.Voilà donc.Bon les choses sont claires sont
établis voilà merci.C'est tout c'est tout.Ben voilà après je pense que si les premières PF un les livres sont au
téléphone c'est par de pharmacie c'est pas l'idéal.Mais.Ouais c'est on avait pas fini la R et D sur CE PC vous
ouais.On travaille avec proximus.Où ces sous-traitants ?Oui et j'ai d'après ce que j'ai pu entendre.Les BU sont pas
nécessairement contentes.De ce parce que le gars qui a designé le PCB il.C'est pas quelqu'un qui a une grosse
expérience dans le monde automotive ? C'est ce que c'est ce que effectivement j'ai cru comprendre de Pierre. Oui mais
enfin ça c'est quand même dingue de la part de Proximus alors ?Merci Monsieur.
|
| 08/09/2025 - 10:00 - Monday |
false |
P153 - Bascule Liège Verviers |
Meeting P153 - Liège Verviers pour projet SAE
Retours
-------
1) Quand conducteur prise de service sans
ordre de marche - voir dans la transcription
2) Jefferson a constaté : pertes de connexion (importance
d'avoir un diagnostic clair des connexions) (voir aussi dans la transcription)
3) Un 3ème problème est
mentionné
Les problèmes de connexion / déconnexion sont rapportés comme rédhibitoires pour LV : sans avoir
résolu ces problèmes de déconnexion, la bascule n'aura pas lieu selon Olivier Stassart.
Transcription
=============
Alors reprend le logiciel en main, ce qui est pas mal. Euh, parce que c'était un de ceux qui
n'avaient pas eu la formation, donc ça c'était déjà une bonne chose. Et alors on a un différent retour. Alors il y
a des points sur lesquels on a déjà échangé. J'ai déjà des éléments de réponse, donc merci.
Quand un
conducteur fait une prise de service ou qu'il sonne au dépôt sans avoir encore fait sa prise de service ou quand il
fait un hall pied et qu'il se met sur la ligne 0, le ticket arrive mais le ticket arrive sans ordre de marche, donc il
ne connaît pas l'horaire, alors on va sur le service matériel pour retrouver l'horaire, mais c'est pas toujours
évident parce que s'il y a une perte de temps et alors en fonction de comment est-ce qu'il le trouve dans la main
courante ? Parfois, il n'arrive.
Puis il ne trouve pas toujours la logique de comment retrouver l'horaire et ça,
il demande vraiment à ce qu'il puisse éditer un ticket pour que quand le conducteur donne l'horaire, il le note. Et
puis après qu'il puisse cliquer pour aller le retrouver, et encore, même quand ils ont ça dans certains cas.
Il
y a des moments où on manque d'une certaine logique pour savoir Ben pourquoi dans un sens on sait que c'était
l'horaire 1006 pour un privé d'Untel et qu'on se retrouve avec un autre numéro. D'e. DM qui n'a aucune logique avec la
ligne et autres. Donc ça c'est il faudrait peut _être un coup de main pour faciliter les outils et peut _être.
Que vous avez déjà des techniques de recherche qui pourraient nous aider. Donc ça, ce sont les. Le premier point. Le
2e point qui lui m'embête encore plus fort, c'est Churchill qui avait. Et ça, c'était Édouard qui l'avait ou
c'était Jefferson qui l'avait constaté.
Le PC de se déconnecterait assez souvent et donc il a des pertes de
connexion, ce qui montre.
Une non-stabilité mais pas liée je pense à ça, d'après ce que j'ai pas dit, mais
plus lié au PC. Sauf que aujourd'hui matin j'ai fait 2 vidéos avec Bruno qui était en table et il a aussi eu des
déconnexions et il a aussi eu le cas où il a dû rafraîchir sa page parce que en.
Il avait acquitté les appels
pour les clôturer et les appels ne se ne se ne se vidaient pas de la page des alertes et il a dû réactualiser pour
voir les appels éliminés et ça, ça risque de coincer parce que il faut vraiment qu'on comprenne pourquoi.
Au
niveau de Churchay, je suis déjà remonté au niveau de l'équipe de Jaurès puisque c'est quelque chose
d'infrastructure et j'ai demandé à Benjamin docquier de regarder en parallèle, j'ai pas le retour non plus, mais là
il faudrait réappuyer aussi d'un point de vue de Bruno qui est là pour le moment parce que ça de nouveau c'est un 2e
point qui est mis ici en place donc voilà.
Pour les 2 points au niveau d'ici et puis après, il y a les points des
mails que dans lesquels il y a des éléments de réponse. Il y a des éléments où Ben, c'est solutionné pour moi,
pas du style. Le télé PLN 4 et 6 Ben OK je savais pas qu'il y avait 2 bus que les bus, le numéro de bus pouvait
_être différent en 4 et en 6.
Ce qu'on a inclus pas dans les 3/4 du temps ou je dirais même les 9/10 du temps,
ils sont les mêmes.
Et alors ? Ben il y a le problème d'affichage. Chauffeur dans des événements, mais là,
vous savez, vous _êtes en train de regarder. Et ma question que moi, j'aurais, où est-ce qu'on en est au niveau du
ticket ? Est-ce que il y aurait moyen d'avoir cette édition-là ? Est-ce qu'il y aurait moyen d'avoir ça dans la
prochaine release avant qu'on fasse le basculement ? Ça c'est ma question, vraiment fondamentale.
|
| 08/09/2025 - 09:40 - Monday |
false |
|
Début de mission du Front-End Developer Malek dans le projet SAE |
| 08/09/2025 - 09:35 - Monday |
false |
|
Accord de Nicolas Duvivier pour inclure le nom des personnes prévues pour participer au déploiement (MeP) + nom de
l'Incident Manager selon proposition de vendredi 05/09 : on devrait modifier la fiche Go/No Go. Propre au projet SAE. |
| 08/09/2025 - 07:41 - Monday |
false |
|
TODO pour le PSR
1) Dans Journal, extraction des events entre deux dates
2) Prendre souscription Mammouth à
10€/mois
3) Étudier l'API de Mammouth pour y faire appel pour le PSR (https://1tribe.win/quicktec/psr.php)
4) Me
faire un projects.xml pour intégrer les données des projets
5) Sauver les données de titre, durée , projets et Key
Message (encore à ajouter)
Composition du PSR
1) Tableau synoptique
Project Responsable Période Date
SAE Patrick
Boens Semaine 36 04/09/2025
Il faut ajouter le code projet dans ce tableau !
2) KPI et RAG
a) budget
b) risques
c)
ressources
d) ... tous les aspects présents dans une page de présentation de projet dans un CoPil
3) Key Messages
4)
Milestones
Une liste de milestones significatives et je dois vérifier ces milestones avec EdCr, ViNa et JeBe. Meeting
positionné pour 09/09 de 13h00 à 14h00
Disposer d'un statut sur les milestones
5) Points de blocage et risques
(heatmap ?)
6) Prochaines actions
|
| 08/09/2025 - 07:29 - Monday |
false |
|
Préparation des objectifs de la semaine :
1) Créer la présentation de base du prochain Steerco
2) Rassembler les
sujets qui devraient faire partie du prochain Steerco
3) Faire la liste des commandes (voir avec Dimitri)
4) Vérifier
si OK pour la présa au Management du rôle de PO avec PiPa
5) Modification de la fiche projet pour PFE
6) Modification
de la fiche projet pour SAE
7) Intégrer les budgets (recevoir feuille Excel de NiFo)
8) Nettoyage de mails (passer de
332 à 300 mails non-lus)
9) Préparation du PSR sur base des éléments du journal (deadline = 12/09/2025)
10)
Extraction des mails significatifs entre le 01/09 et 12/09/2025 (pour rapport PSR du 12/09)
11) Extraction des mails
significatifs entre le 15/06/2025 et 31/08/2025 |
| 05/09/2025 - 17:00 - Friday |
false |
|
Proposition d'ajout au Go/No Go:
1) Le nom des personnes participant au déploiement est connu
2) Le nom de l'Incident
Manager est connu (proposition : Eduard ou Patrick)
Accord de Nicolas Duvivier le 08/09 |
| 05/09/2025 - 14:00 - Friday |
false |
|
Projet bloc COM (Next G)
Ordre du jour de la réunion:
1. Option d'installation des blocs COM (par la BU ou
Proximus)
2. Planning de mise à disposition du matériel par Proximus
3. Décommissionnement de la 2G et impact sur le
projet
4. Volume de blocs COM à commander (bus et trams) et spares
5. Remplacement du GSM contrôle existant
Contenu
de la réunion:
• Installation des blocs COM: Charleroi souhaite que la BU installe les blocs COM elle-même, en
conservant la maîtrise du hardware et en pouvant intervenir rapidement en cas de problème. La sous-traitance est
perçue comme une fausse bonne idée, engendrant plus de gestion et moins de qualité. La BU a les ressources et la
proximité nécessaires pour gérer l'installation dans ses propres dépôts.
• Planning de Proximus: Un décalage de
2 à 3 semaines est observé sur le planning initial à cause d'un redesign du PCB. Proximus a désigné un chef de
projet depuis peu et doit fournir un planning détaillé avec des dates précises. La cadence initiale de 20 blocs
assemblés et installés par jour est jugée insuffisante, surtout avec la contrainte des trams à Charleroi.
•
Décommissionnement de la 2G: Bien que le décommissionnement complet soit prévu pour fin 2029, Proximus pourrait ne
plus assurer le support en cas de problème dès juin 2026. Il est important que le matériel ferroviaire (trams) soit
servi en priorité, compte tenu de la localisation géographique de Charleroi.
• Volume et spares: Un besoin d'environ
3000 blocs COM est estimé, avec une vision plus claire du parc de chaque BU à préciser. Le calcul des spares se fera
au prorata de la taille du parc de chaque BU, mais un nombre plus important de spares est souhaité pour les trams.
•
GSM contrôle existant: Une question est posée concernant la nécessité de remplacer les GSM contrôle déjà
présents dans certains véhicules, notamment ceux récupérés dans les trams. Leur fiabilité et leur compatibilité
avec la nouvelle solution doivent être évaluées.
• Nouveau design PCB: Des tests sur le terrain sont prévus, mais
l'équipe a demandé des tests de cyclage thermique indépendants. Des défauts de conception ont été identifiés et
remontés à Proximus, notamment l'absence de protection sur les entrées et l'utilisation de composants obsolètes. Le
design actuel n'est pas considéré comme fiable.
Conclusion de la réunion:
• Le pilotage de l'installation des
blocs COM reste sous la responsabilité de la BU.
• Il est crucial d'obtenir rapidement un planning précis de
Proximus et d'augmenter la cadence d'installation.
• Une attention particulière doit être portée aux trams et à la
question du décommissionnement de la 2G.
• La question du remplacement des GSM contrôle existants et les problèmes
liés au design du PCB doivent être résolus.
Prochaines étapes à planifier:
1. Vincent doit envoyer les données
précises sur le parc de chaque BU, avec une distinction pour les trams, au plus tard début de semaine prochaine.
2.
Récupérer le planning détaillé de Proximus et rediscuter de la cadence d'installation.
3. Obtenir une réponse de
Proximus concernant le remplacement des GSM contrôle existants.
4. Clarifier les tests supplémentaires à effectuer
sur le nouveau PCB et évaluer l'opportunité de tests de cyclage thermique indépendants.
5. Meeting avec Proximus
concernant les défauts de conception du PCB.
|
| 05/09/2025 - 14:00 - Friday |
false |
|
Sujet : incidents lors de la mise en production de la release Statham - Minutes officielles attendues de
Jérémy.
Ordre du jour de la réunion:
1. Différentes sujets plus ou moins techniques liés à la mise en
production
2. Je n'en ai retenu que les parties liées aux processus et méthodes
3. Amélioration de la
communication
Contenu de la réunion:
• Il a été constaté un manque de clarté dans la communication, donnant
l'impression d'un manque d'organisation. Une proposition est faite pour désigner une ou plusieurs personnes
responsables de la communication via un canal dédié (chat) utilisé uniquement pour diffuser des informations, et non
pour des échanges ou demandes d'informations.
• Rappel des bonnes pratiques :
- Ne pas laisser plusieurs personnes
communiquer simultanément : cela provoque confusion et perte de temps.
- Nommer explicitement le responsable
communication au début de la gestion de crise.
- Mettre à jour le management et les utilisateurs « le plus tôt
possible et aussi souvent que nécessaire » avec honnêteté et sans cacher les incertitudes mais aussi le plus
clairement possible : le canal de communication doit, dans ce cas, être presque à sens unique ... du projet vers les
utilisateurs et le management
• Nécessité de disposer de personnes qui peuvent aider MiKe avec la mise en production
(cfr. remarque de Gaspar du scrum de mercredi matin)
• Rollback pas efficient et risquant de poser plus de
problèmes.
• Devraient être accompagné par les DevOps
Conclusion de la réunion:
• Amélioration de la
communication
• Réflexion sur le rollback (en particulier, les data)
• Demande de minutes contenant une série
d'actions concrètes pour améliorer notre prochain déploiement. Les actions (en nombre limité, les plus importantes
d'abord) doivent être prises dans le backlog de l'équipe.
Prochaines étapes à planifier:
1. Désigner une ou des
personnes responsables de la communication (Incident Manager ?)
|
| 05/09/2025 - 13:03 - Friday |
false |
|
At-on des retours sur l'enquête de satisfaction de la stabilisation de SAE ? Mail à ViNa, EdCr, JeBe, DaHa |
| 05/09/2025 - 12:56 - Friday |
false |
|
Mails envoyés à NiFo :
1) Pour la gestion des commandes dans le projet PFE
2) Pour la vérification des factures des
fournisseurs (est-ce que ce qui est facturé correspond bien à ce qui a été presté et/ou livré?)
|
| 05/09/2025 - 10:30 - Friday |
false |
|
Suivi du projet Bloc-Com et des commandes
Ordre du jour de la réunion:
1. État d'avancement du PCB (Printed Circuit
Board)
2. Recours à un laboratoire externe pour les tests
3. Planification des installations des Bloc-Com
4. Gestion
des commandes
Contenu de la réunion:
• État d'avancement du PCB:
• Les remarques concernant le PCB ont été
transmises à Proximus. Juan Fernandez a revu les remarques.
• Un document avec les recommandations de composants a
été envoyé à Proximus.
• Une réunion est prévue lundi avec Proximus, Namur et Juan Fernandez pour expliquer les
demandes et répondre aux interrogations du sous-traitant de Proximus
• Estimation à 4-5 jours le temps nécessaire
pour adapter le PCB en fonction des demandes.
• Les 2 MC 100 pour les 2 platines seront fournis par l'entreprise, le
reste des composants devant être approvisionné par Proximus.
• Proximus effectuera des tests internes sur les
platines fabriquées avant de les envoyer pour des tests en interne, puis dans 2 bus pour finaliser la validation du
PCB.
• Recours à un laboratoire externe pour les tests:
• Une réunion est prévue avec le directeur technique du
Hainaut pour discuter de la nécessité d'un test de stress thermique supplémentaire, compte tenu de l'impact potentiel
sur le planning.
• Lors de la PFEV précédente, les tests avaient été sous-traités à Contrôle, mais il n'y a pas
de traces des tests réalisés.
• Le profil du stress thermique devra être défini par le Tech, en simulant les
conditions rencontrées dans un bus.
• Planification des installations des Bloc-Com:
• L'entreprise dispose de 50 MC
100, qui seront fournis à Proximus. Le reste des commandes est à la charge de Proximus.
• Un planning détaillé a
été refait, mais des informations de Proximus sont manquantes.
• Les responsables de Proximus sont en congé, ce qui
pose problème pour la planification.
• Les réunions avec les directeurs techniques des BU sont en cours pour
déterminer si l'installation sera faite en interne ou sous-traitée à Proximus. Sur les 3 DT rencontrés, 2 souhaitent
sous-traiter à Proximus et 1 veut tout faire en interne.
• Il est important d'obtenir une offre standard de Proximus
avant de leur communiquer le nombre de BU concernées.
• Christian a demandé à Proximus de faire des offres en
fonction du nombre d'installations.
• Christian a évoqué la possibilité que les installations se fassent uniquement
dans les bus en régie.
• Une liste de tous les dépôts, en régie ou chez les loueurs, a été envoyée à
Proximus.
• Les BU ont été sollicitées pour fournir des informations sur le nombre de bus, le nombre de PFEV2
installés, et leurs plans pour l'année prochaine.
• La planification des visites de Proximus et du tech dans les
différentes BU a commencé pour anticiper le mode de fonctionnement.
• Il faut préparer des modes opératoires
d'installation et des procédures de validation.
Gestion des commandes:
• La gestion des commandes n'est pas prise
en charge.
• L'état des commandes est inconnu et il est urgent de clarifier qui est responsable de cette tâche.
•
L'état des commandes doit être amené à l'attention de Nicolas et Christian.
• Les commandes de Bloc-Com sont
gérées, ce qui inclut le GSM, le Voicing et le GSM Data.
• Le slide de Benoît sera envoyé pour illustrer le
Bloc-Com.
• Le planning détaillé inclut les commandes, mais des informations de Proximus sont nécessaires.
• La
question du paiement des factures de Proximus est gérée par Laurence. Il faut s'assurer d'être informé rapidement
des commandes passées.
• La décomposition des coûts (assemblage, installation, project management) est définie
dans une offre de Proximus.
Conclusion de la réunion:
• La gestion des commandes doit être clarifiée rapidement
car l'état actuel est inacceptable.
• Le manque d'écoute et la monopolisation de la parole dans les réunions sont
pointés du doigt.
Prochaines étapes à planifier:
1. Réunion lundi avec Proximus, Namur et Juan Fernandez pour le
PCB.
2. Réunion avec le directeur technique du Hainaut pour le test de stress thermique.
3. Attendre le retour des BU
concernant les informations sur le parc de bus.
4. Organiser les visites de Proximus et du tech dans les BU.
5.
Clarifier la gestion des commandes avec Nicolas et Christian.
6. Envoyer le planning détaillé.
7. Obtenir les
informations manquantes de Proximus dans le planning.
Affaires en attente de traitement et affaires laissées pour
compte:
1. Offre standard de Proximus pour les installations.
2. Définition du profil de stress thermique.
3.
Facturation et suivi des coûts du project management de Proximus.
|
| 05/09/2025 - 07:00 - Friday |
false |
|
Mise à jour de la présentation Product Ownership pour Managers. Donnée à PiPa pour révision (procédures et
méthodes sont chez lui). |
| 04/09/2025 - 16:00 - Thursday |
false |
|
Rattrapage des mails en retard |
| 04/09/2025 - 10:02 - Thursday |
false |
|
react.js : aurions-nous un manque d'expertise dans ce composant technologique ? |
| 04/09/2025 - 00:00 - Thursday |
true |
|
Début de la création de l'outil de "Journaling" (celui que j'utilise ici -- LogBook) pour réaliser :
1) Des
rapports hebdomadaires automatiques (nouvel outil à construire) (PSR - Project Status Report)
2) Utilisation des
rapports hebdomadaires et du journaling pour la génération du CoPil |
| 03/09/2025 - 16:00 - Wednesday |
false |
|
Rattrapage des mails en retard |
| 03/09/2025 - 10:13 - Wednesday |
false |
|
Création de la première version de la présentation pour Management de la notion de PO à la demande de PiPa |
| 03/09/2025 - 09:00 - Wednesday |
false |
|
Préparation cours PO - Cycle Planning |
| 02/09/2025 - 16:00 - Tuesday |
false |
|
Rattrapage des mails en retard |
| 02/09/2025 - 10:00 - Tuesday |
false |
|
Mise en production de la release Statham. MeP longue (52 minutes) et problèmes de release (bugs) avec impact mineur sur
les utilisateurs (pas tous et pas toutes les BUs impactées) |
| 02/09/2025 - 09:00 - Tuesday |
false |
|
Adaptation du cours PO pour PiPa (partie 2) |
| 02/09/2025 - 00:00 - Tuesday |
true |
|
Petites améliorations dans l'outil de gestion des CoPils (Steercos). Ce qu'il serait maintenant souhaitable de faire
c'est s'occuper de la génération quasi automatique de la présentation du CoPil avec, en exergue, les RAGs de la page
d'entête de PFE, de la page d'entête de SAE, un calcul automatique du RAG de la page d'entête du programme (synthèse
des deux autres RAGs, PFE et SAE), et génération automatique de page internes pour chaque projet en accord avec un
journal des événements (et surtout les événements clefs). |
| 01/09/2025 - 16:00 - Monday |
false |
|
Réponse positive du candidat Kibambe pour le poste DevOps. Accord de commencer le 20251001 |
| 01/09/2025 - 16:00 - Monday |
false |
|
Rattrapage des mails en retard |
| 01/09/2025 - 10:21 - Monday |
false |
|
La salle B0038 chez Engie a été réservée pour le 15/09 entre
13h et 16H pour la démo Statham (SAM
présente). C'est la première démo organisée
comme ce que l'Agilité préconise |
| 01/09/2025 - 10:05 - Monday |
false |
|
Adaptation du cours PO pour PiPa |
| 01/09/2025 - 09:00 - Monday |
false |
|
Demande de Sara et David de compléter article Interview pour SAM Central |
| 01/09/2025 - 00:00 - Monday |
true |
|
Création d'un micro outil de gestion de steercos (suite). Outil opérationnel mais encore perfectible. Permet de
réduire le temps de préparation des CoPils à venir. |
| 29/08/2025 - 16:00 - Friday |
false |
|
Rattrapage des mails en retard |
| 29/08/2025 - 09:00 - Friday |
false |
|
Dernières interviews pour le poste de DevOps : 3 interviews au menu dela journée |
| 29/08/2025 - 00:00 - Friday |
true |
|
Création d'un micro outil de gestion de steercos |
| 28/08/2025 - 16:00 - Thursday |
false |
|
Rattrapage des mails en retard |
| 28/08/2025 - 08:00 - Thursday |
false |
Différents outils |
Différents outils sont développés qui permettent une gestion automatique avancée dans l'organisation du programme
SAM :
1) PSR : création d'un Project Status Report automatisé
2) Journal : journal d'événements (ce qui s'est
passé dans un projet ou dans l'ensemble du programme) et qui constitue la "nourriture" dont les outils, dont il est
question ici, se serviront. Il est à noter que ce petit utilitaire peut produire un output en mode "web service" pour
extraire les éléments entre deux dates (utile, par exemple, pour nourrir un PSR établi entre deux dates)
3)
Steercos.php : données de base d'un Steerco afin de ne pas être obligé d'ouvrir une cascade de documents PowerPoint
afin de trouver une information concernant un CoPil. Steercos.php peut se nourrir de PSR pour générer automatiquement
la matière première d'un CoPil (Steerco). Cet outil, étant donné sa nature sera le dernier qui sera prêt. Le
souhait est que cet outil puisse servir à générer la matière de base du CoPil du 09/10/2025 prochain. |
| 27/08/2025 - 16:00 - Wednesday |
false |
|
Rattrapage des mails en retard |
| 26/08/2025 - 16:00 - Tuesday |
false |
|
Rattrapage des mails en retard |
| 26/08/2025 - 14:19 - Tuesday |
true |
Compteurs d'utilisation des features |
De : BOENS Patrick
Envoyé : mardi 26 août 2025 14:19
À : DSE.Demande
Objet : Demande de
disposer de compteurs d'utilisation
Bonjour,
En tant que Chef de programme je souhaite connaître les parties
essentielles, particulièrement utiles, des logiciels que nous construisons, ici SAE. Pour être en mesure d’orienter
les développements ou simplement l’effort de peaufinage à apporter, je souhaiterais disposer de compteurs
d’utilisation (qui sont à définir) qui me permettront de savoir ce qui est vraiment utilisé de ce qui ne l’est
pas.
Voici une réflexion générale sur le sujet telle que générée par l’IA :
Les compteurs d'utilisation de
fonctionnalités servent à mesurer combien de fois, et comment, certaines parties d'un logiciel sont utilisées par ses
utilisateurs. Cela permet, même sans être spécialiste, de répondre à plusieurs grands besoins des équipes de
développement, du support et du management.userpilot+1
Utilités principales
Les compteurs d'utilisation permettent de
savoir quelles fonctionnalités sont vraiment adoptées ou délaissées dans un logiciel. Cela aide à mieux comprendre
les vrais besoins des utilisateurs, et donc à concentrer les efforts sur les parties les plus utiles du
produit.brainhub+1
Amélioration continue
En suivant ces données d'utilisation, on peut repérer :
• Les
fonctionnalités populaires à conserver et à améliorer
• Celles peu utilisées, à simplifier, rendre plus visibles
ou éventuellement supprimer
• Les moments où les utilisateurs rencontrent des difficultés, afin d'améliorer leur
expérienceuserpilot+1
Prise de décision et gestion du budget
Pour le management, ces compteurs permettent de piloter
les priorités de développement de manière objective : investir dans les fonctionnalités qui comptent vraiment selon
l'usage réel, éviter de gaspiller du temps et du budget sur des éléments inutiles, et optimiser le renouvellement ou
la suppression de licences logicielles si certaines applications ne sont jamais utilisées.manageengine+1
Satisfaction
et fidélisation des utilisateurs
Enfin, en adaptant le logiciel en fonction des usages réels, on augmente la
satisfaction des utilisateurs, ce qui favorise leur fidélisation et le succès du logiciel dans la durée.brainhub+1
En
résumé, les compteurs d'utilisation sont des outils essentiels pour piloter un logiciel de façon éclairée, centrer
l'effort sur les vraies priorités et améliorer l'expérience des utilisateurs de manière
continue.manageengine+2
Citations / Sources
:
1. https://userpilot.com/blog/feature-usage-/
2. https://brainhub.eu/library/how-to-measure-feature-usage
3. https://
www.manageengine.com/fr/desktop-central/software-metering.html
4. https://learn.microsoft.com/fr-fr/windows/win32/perfct
rs/about-performance-counters
5. https://www.scopemaster.com/fr/blog/points-de-fonction/
6. https://www.gestisoft.com/fr
/blogue/les-fonctionnalites-dun-logiciel-erp-un-resume-complet
7. https://www.hivepower.tech/fr/blog/comprendre-les-syst
%C3%A8mes-de-gestion-des-compteurs
8. https://www.teamleader.eu/fr/blog/avantages-logiciel-de-suivi-du-temps
9. https://
countthings.com/fr/overview
10. https://vorecol.com/fr/blogs/blog-quels-sont-les-avantages-et-les-inconvenients-des-logi
ciels-de-suivi-des-performances-en-temps-reel-pour-les-managers-22854
|
| 26/08/2025 - 14:19 - Tuesday |
true |
Compteurs d'utilisation des features |
De : BOENS Patrick
Envoyé : mardi 26 août 2025 14:19
À : DSE.Demande
Objet : Demande de
disposer de compteurs d'utilisation : amélioration de notre monitoring de qualité
Bonjour,
En tant que Chef de
programme je souhaite connaître les parties essentielles, particulièrement utiles, des logiciels que nous
construisons, ici SAE. Pour être en mesure d’orienter les développements ou simplement l’effort de peaufinage à
apporter, je souhaiterais disposer de compteurs d’utilisation (qui sont à définir) qui me permettront de savoir ce
qui est vraiment utilisé de ce qui ne l’est pas.
Voici une réflexion générale sur le sujet telle que générée
par l’IA :
Les compteurs d'utilisation de fonctionnalités servent à mesurer combien de fois, et comment, certaines
parties d'un logiciel sont utilisées par ses utilisateurs. Cela permet, même sans être spécialiste, de répondre à
plusieurs grands besoins des équipes de développement, du support et du management.userpilot+1
Utilités
principales
Les compteurs d'utilisation permettent de savoir quelles fonctionnalités sont vraiment adoptées ou
délaissées dans un logiciel. Cela aide à mieux comprendre les vrais besoins des utilisateurs, et donc à concentrer
les efforts sur les parties les plus utiles du produit.brainhub+1
Amélioration continue
En suivant ces données
d'utilisation, on peut repérer :
• Les fonctionnalités populaires à conserver et à améliorer
• Celles peu
utilisées, à simplifier, rendre plus visibles ou éventuellement supprimer
• Les moments où les utilisateurs
rencontrent des difficultés, afin d'améliorer leur expérienceuserpilot+1
Prise de décision et gestion du
budget
Pour le management, ces compteurs permettent de piloter les priorités de développement de manière objective :
investir dans les fonctionnalités qui comptent vraiment selon l'usage réel, éviter de gaspiller du temps et du budget
sur des éléments inutiles, et optimiser le renouvellement ou la suppression de licences logicielles si certaines
applications ne sont jamais utilisées.manageengine+1
Satisfaction et fidélisation des utilisateurs
Enfin, en adaptant
le logiciel en fonction des usages réels, on augmente la satisfaction des utilisateurs, ce qui favorise leur
fidélisation et le succès du logiciel dans la durée.brainhub+1
En résumé, les compteurs d'utilisation sont des
outils essentiels pour piloter un logiciel de façon éclairée, centrer l'effort sur les vraies priorités et
améliorer l'expérience des utilisateurs de manière continue.manageengine+2
Citations / Sources
:
1. https://userpilot.com/blog/feature-usage-/
2. https://brainhub.eu/library/how-to-measure-feature-usage
3. https://
www.manageengine.com/fr/desktop-central/software-metering.html
4. https://learn.microsoft.com/fr-fr/windows/win32/perfct
rs/about-performance-counters
5. https://www.scopemaster.com/fr/blog/points-de-fonction/
6. https://www.gestisoft.com/fr
/blogue/les-fonctionnalites-dun-logiciel-erp-un-resume-complet
7. https://www.hivepower.tech/fr/blog/comprendre-les-syst
%C3%A8mes-de-gestion-des-compteurs
8. https://www.teamleader.eu/fr/blog/avantages-logiciel-de-suivi-du-temps
9. https://
countthings.com/fr/overview
10. https://vorecol.com/fr/blogs/blog-quels-sont-les-avantages-et-les-inconvenients-des-logi
ciels-de-suivi-des-performances-en-temps-reel-pour-les-managers-22854
|
| 25/08/2025 - 16:00 - Monday |
false |
|
Rattrapage des mails en retard |
| 25/08/2025 - 14:00 - Monday |
false |
|
PFE : Sprint Review : PiPa a largement interrompu cette Review sur des questions un peu théoriques. Intéressant
cependant et demande de pouvoir effectuer des MeP "on-demand" pourvu que le processus soit effectivement respecté (PiPa
ne s'est pas encore occupé de faire valider ce processus ce qui ne le rend pas applicable). Par la suite, NiFo exprime
sa volonté d'avoir un GO/No Go officiel pour PFE quand bien même l'équipe procède par release en pré-prod (Canary
Release) qui garantit le bon fonctionnement de la release sur un nombre limité de bus. |
| 25/08/2025 - 13:30 - Monday |
false |
|
Comité SAM Central : communication sur SAM |
| 25/08/2025 - 11:00 - Monday |
false |
|
Point mensuel SAM, PFE, et SAE avec PiBo |
| 25/08/2025 - 08:00 - Monday |
false |
|
Préparation de ma semaine (comme tous les lundis) : je passe en revue tous les sujets sur lesquels je dois me pencher
durant la semaine à venir |
| 22/08/2025 - 14:30 - Friday |
false |
|
Debriefing sur meeting KUs :
Il semble que le meeting, originellement prévu pour connaître le point de vue de chaque
BU quant au montage du bloc comm dans leurs bus, ait finalement été l'occasion pour certaines BU (au moins Hainaut) de
mettre en cause le bloc comm et d'exiger des tests effectués par un laboratoire indépendant. La question de savoir si
cela avait été demandé dans les versions antérieures des PFE mais personne ne semble savoir si ce genre de tests
d'usine ont été effectués ni où se trouvent leurs éventuels rapports. Cette absence de documentation nous met en
peine de justifier un éventuel refus de réaliser les tests qui nous sont demandés. NiFo prend la position de dire :
OK, on fait les tests, mais on ne change pas le planning. |
| 22/08/2025 - 10:15 - Friday |
false |
|
Demandes en souffrance meeting avec ViNa, JeBe, PiBo, EdCr, ...
Finalement le meeting a été annulé et remis à une
date ultérieure |
| 21/08/2025 - 16:00 - Thursday |
false |
|
Demandes en souffrance : préparation pour ViNa et JeBe pour le lendemain |
| 21/08/2025 - 14:30 - Thursday |
false |
|
Réunion de Staff Management |
| 21/08/2025 - 13:00 - Thursday |
false |
|
Meeting de Go/No Go sur release Statham (Transporteurs) en retard de ± 8 jours.
Meeting ponctué par un GO
conditionnel : certains bugs doivent être résolus pour vendredi 22 pour qu'on puisse se lancer dans la MeP le mardi
qui suit. |
| 20/08/2025 - 13:00 - Wednesday |
false |
|
Discussion et lancement immédiat concernant une enquête de satisfaction de la stabilisation de SAE. Est-ce qu'on y est
ou pas ? |
| 19/08/2025 - 14:00 - Tuesday |
false |
|
Recap NextG / Blocs Comm |
| 19/08/2025 - 12:00 - Tuesday |
false |
Go/No Go |
Création du document Go/NO Go en vue d'en améliorer la préparation des mises en production (document de 4 pages, à
l'intention de Équipe Dev, Management, Support -- Owner = Eduard Creciun) |
| 19/08/2025 - 10:00 - Tuesday |
false |
|
Préparation Hackathon et passage en revue des demandes en souffrance |
| 19/08/2025 - 09:40 - Tuesday |
false |
Enquête de satisfaction sur stabilité SAE |
FIN DE L'INCORPORATION DE MES MAILS - FIN DE L'INCORPORATION DE MES MAILS - FIN DE L'INCORPORATION DE MES MAILS - FIN DE
L'INCORPORATION DE MES MAILS - FIN DE L'INCORPORATION DE MES MAILS - FIN DE L'INCORPORATION DE MES MAILS - FIN DE
L'INCORPORATION DE MES MAILS - FIN DE L'INCORPORATION DE MES MAILS - FIN DE L'INCORPORATION DE MES MAILS - FIN DE
L'INCORPORATION DE MES MAILS - FIN DE L'INCORPORATION DE MES MAILS - FIN DE L'INCORPORATION DE MES MAILS - FIN DE
L'INCORPORATION DE MES MAILS - |
| 19/08/2025 - 09:30 - Tuesday |
true |
Enquête de satisfaction sur stabilité SAE |
Meeting avec DaHa pour création de l'enquête de satisfaction |
| 19/08/2025 - 08:45 - Tuesday |
false |
|
Meeting sur Transporteurs - Phase 2
Christian veut savoir ce que contient précisément la phase 2 de Transporteurs or
cette phase est définie dans le cycle 4 et le Cycle Planning n'a pas encore eu lieu.
Il y a incompréhension sur ce
que le Management attend et le fonctionnement des méthodes agiles. |
| 18/08/2025 - 16:13 - Monday |
true |
Engagement Malek : expert front-end |
De : CRECIUN Eduard
Envoyé : lundi 18 août 2025 16:13
À : FORGET Nicolas
Cc : BOENS Patrick ; PAELINCK Pierre
Objet
: RE: [SELECTED FOR CONTRACTING]Expert Web Front End (Front End Symfony/Typescript/Temps Réel) - MALEK CHERIF
Bonjour,
J’ai eu son retour et tout est en ordre pour qu’il commence dans une semaine. La date est à confirmer encore.
Le
prix journalier est de 645€ à la place de 660€ annoncé.
@FORGET Nicolas peut-on se voir demain dans la journée
pour continuer sa candidature ?
Cordialement,
Eduard C.
|
| 18/08/2025 - 10:46 - Monday |
true |
Planning SAE (Cycles 3 et 4) |
De : CRECIUN Eduard
Envoyé : lundi 18 août 2025 10:46
À : BOENS Patrick
; NAVEZ Vincent
Cc : KEINBORG Michael
Objet
: RE: IMPORTANT et URGENT : Planning SAE
Salut Patrick,
1. Tram de Liège : qu’est-ce qu’on a exactement dedans ?
a. Taux exécution ? : les voyages des trams de Liège ne sont pas comptabilisés et les dispatcheurs ne doivent pas
les qualifier. C’est fait.
b. Lecture des incidents SAE INEO Trams dans SAM ? : seule l’analyse est faite. Aucun
développement prévu à ce jour. C’est une demande extra non planifiée encore.
c. Autre chose ?
2. Les sujets en
cycles :
a. Cycle 3 :
i. Transporteurs phase 1
ii. Tests pour décom CCS. Dépendance de G4s et correspondance (voir
le mail retour de Christian)
iii. Extra : pause sanitaire, SOC (charge des véhicules électriques ET hybrides) avec
leurs carburants respectifs
iv. Intégration gestion appels Radio Charleroi dans SAM
v. Aribus ?
b. Cycle 4 :
i. Transporteurs phase 2 -> supprimer voyage à partir de SAE à envoyer vers SIV et COMET
ii. Décommission CCS /
Géoloc
iii. Améliorations Front End / travail de fond (accompagnés d’un expert Front end)
iv. Améliorations
Déploiement Continu (accompagné d’un expert CD)
v. Intégration accès aux interfaces radios intégrées dans les
Trams pour les mises à jour à distance et les logs
vi. Extra ? : Service agent à confirme encore (je dois
m’occuper de l’analyse fonctionnelle avant tout développement et approuver par le PO) Ceci si confirmé, sera
développé par Maxime B.
3. Suppression partielle de voyages ? :
a. On dépend de la nouvelle structure Hastus -> mise
en pause
b. L’analyse n’est pas finie
c. Personne n’est prévue sur ce sujet
d. Suggestion : à développer
seulement lorsque le nouveau flux de donnée sera mis en place (Que ce soit ESB, Hastus ou autres…)
Voilà ce que
j’ai de mémoire, j’espère que ca t’a aidé
Bat,
Eduard
|
| 18/08/2025 - 10:00 - Monday |
false |
|
Préparation Hackathon et passage en revue des demandes en souffrance |
| 15/08/2025 - 14:00 - Friday |
true |
PSR |
Création de la structure d'un PSR. Nicolas demande à être proche du layout CoPil. La création d'un PSR a été
évoquée lors du Staff Management meeting du 14/08 sans avoir néanmoins de décision sur le sujet. Le sujet a été
abordé en conjonction avec un éventuel meeting mensuel concernant le Statut projet. Le meeting n'est pas arrivé à
une conclusion par contre Patrick Boens est demandeur de réaliser un PSR hebdomadaire ce qui permet d'ailleurs de
s'alimenter sur base de rapports déjà clairement établis pour les CoPils. |
| 15/08/2025 - 10:45 - Friday |
false |
|
Synchro blocs comm |
| 15/08/2025 - 09:00 - Friday |
false |
|
Passage en revue des mails en souffrance |
| 14/08/2025 - 14:30 - Thursday |
false |
|
Réunion Staff Meeting |
| 14/08/2025 - 13:00 - Thursday |
true |
|
Interview spécialiste front-end Malek : c'est lui qui sera finalement choisi s'il accepte de venir travailler 3
jours/semaine sur site |
| 14/08/2025 - 11:13 - Thursday |
true |
Report des tests de Liège Verviers (LV) |
De : STASSART Olivier
Envoyé : jeudi 14 août 2025 11:13
À : BOENS Patrick
; MARCOS Sara ; DUVIVIER Nicolas
Objet : Sam
– Tests T3 : Report au 25/08
Bonjour,
En raison d’un manque d’effectif et d’une intervention sur le TRAM
nécessitant un secteur supplémentaire, nous avons dû reporter nos tests initialement prévus le 18/08 au
25/08.
J’ai contacté Nicolas afin de lui éviter un déplacement inutile sur LV et pour vérifier sa disponibilité
à la nouvelle date. Il a confirmé qu’il serait présent le 25/08.
Bonne journée,
|
| 14/08/2025 - 11:00 - Thursday |
false |
|
Interview spécialiste front-end : Dinu |
| 14/08/2025 - 10:07 - Thursday |
true |
Détail de Transporteurs |
De : KEINBORG Michael
Envoyé : jeudi 14 août 2025 10:07
À : BOENS Patrick
; NAVEZ Vincent
Cc : CRECIUN Eduard
Objet :
RE: Transporteurs
Hello
Voici ce qu'on projette:
Cycle 3 :
Transporteur phase 1
Optimisation de la vue carto
historique
DECO CCS
DEC0 GEOLOC
Test Automatisé
Analyse technique
Transporteur phase 2 : analyse technique
Carburant
Cycle 4 :
Transporteur phase 2 :
.Service matériel (écriture)
.Tableau des depart
.voyage
(écriture)
.Alerte
.Rapport
.Log
|
| 14/08/2025 - 09:00 - Thursday |
false |
|
Après plusieurs demandes les deux semaines antérieures, demandes qui n'ont pas été satisfaites, on devrait avoir la
réponse de MiKe et ViNa concernant les features de "Transporteurs" qui seront développés en cycles 3 (suite et fin du
cycle) et 4 (les nouvelles choses) |
| 13/08/2025 - 16:37 - Wednesday |
false |
Automatisation de la gestion des demandes de DSE (Demand Management) |
Fin de non-recevoir sur l'automatisation du traitement de la boîte dse.demande@letec.be
De : POCHET Christian
Envoyé : mercredi 13 août 2025 16:37
À : BOENS Patrick ; BLOOM
Philippe
Cc : BOUCHAT Pierre-Michel ; PAELINCK Pierre
; NAVEZ Vincent ; CRECIUN Eduard ; FORGET
Nicolas ; TIELMANCE Benoît
Objet : RE: IMPORTANT : Processus de
demandes
Bonjour,
Dans le cadre de nos procédures de sécurité, il n’est pas autorisé à faire du scripting sur
une boite email.
Je mets Benoit en copie car cela touche directement au département opérationnel.
Bien à
vous,
Christian
De : BOENS Patrick
Envoyé : mercredi 13 août 2025 16:22
À : BLOOM
Philippe
Cc : BOUCHAT Pierre-Michel ; PAELINCK Pierre
; NAVEZ Vincent ; CRECIUN Eduard ; FORGET
Nicolas ; POCHET Christian
Objet : IMPORTANT : Processus de
demandes
Importance : Haute
Hello Philippe,
Nous avons mis au point un processus de gestion de la demande temporaire
en attendant celui qui devrait être mis en place au niveau de tout l’IT.
Tu peux en trouver le descriptif ici :
Processus de gestion des demandes.docx
Ce processus demande quand même pas mal de travail pour le PO, ViNa, et nous
aimerions le soulager au maximum.
Pour ce faire, nous aimerions avoir accès temporairement à la mailbox
des.demande@letec.be afin de traiter la demande le plus automatiquement possible.
Dès lors peux-tu t’assurer que
nous recevions les accès à la mailbox pour que nous puissions extraire les nouveaux mails automatiquement via un
script PHP ?
Merci infiniment,
Patrick
|
| 13/08/2025 - 12:54 - Wednesday |
true |
|
De : GOMEZ Julien
Envoyé : mercredi 13 août 2025 12:53
À : BOENS Patrick
; PAELINCK Pierre ; DSE.Demande ; NAVEZ Vincent
Cc : LEFEBVRE Alexis ; DUCHATEAU Dimitri
Objet : RE: IMPORTANT et URGENT : Détermination des lignes de bus d'agressions
nombreuses
Hello,
Voici les données des lignes de bus d’agressions nombreuses et de zones blanches.
Mes remarques
précédentes restent d’application.
A+,
Julien
le mail s'accompagne d'un rapport. |
| 13/08/2025 - 10:00 - Wednesday |
false |
|
Grosse préparation antérieure sur la convergence PFE et SAE. Premiers éléments à travailler : définir le rôle du
PO, mettre ViNa et JeBe aux bons endroits, question de définition de Product Manager (SAM ou carrément DSE) (ViCo ?) |
| 13/08/2025 - 09:26 - Wednesday |
true |
Correspondances bus-bus et Appels de détresse BW |
Mail de ChPo
Bonjour Eduard, Patrick,
Je propose d’inscrire ces deux sujets à l’ordre du jour du prochain COPIL
:
• Correspondances bus-bus
• Appels de détresse BW
Pour chacun, il serait utile de préparer :
1. Un slide de
contexte présentant la situation actuelle et les contraintes.
2. Un slide de pistes de solutions.
3. Une estimation
budgétaire approximative pour un développement temporaire
Cela permettra au COPIL de décider sur base
d’éléments factuels, en priorisant les actions et les moyens à engager.
Voila ce que j’entrevois comme pistes
(à challenger)
• Correspondances bus-bus
a. Laisser CCS en service jusqu’à reprise par Hastus ou panne bloquante
(non recommandé).
b. Expliquer la situation au métier et suspendre la fonctionnalité, en faisant de Namur et BW des
pilotes du projet Hastus.
c. Lancer un développement temporaire pour gérer les correspondances (non
recommandé).
• Appels de détresse BW
a. Développement spécifique pour un traitement dédié (non recommandé).
b.
Déroutage des appels vers un autre dispatch en dehors des heures.
c. Renforcement du dispatch BW pour permettre un
shift complet.
Est-ce que cela vous parait cohérent ?
Bien à vous,
Christian
-----------------------
Suite à ce
mail, j'ai eu la réflexion suivante de la part de PiBo:
De : BOUCHAT Pierre-Michel
Envoyé : mercredi 13 août 2025 09:45
À : BOENS Patrick
Objet : TR: Correspondances Bus-bus
- point bloquant
Bonjour Patrick,
Je t’avoue qu’aujourd’hui, à la lumière du mail de Christian, je vois
difficilement le rôle du PO (ViNa) tel que tu me l’as expliqué.
Hier encore, j’ai eu une discussion avec Christian
où il me précisait que Leurident aurait aimé pouvoir bloquer certaines actions des développeurs. (Je ne sais plus te
dire sur quel sujet).
A+
Pierre
Je dois bien reconnaître qu'effectivement il existe un grave flottement concernant le
rôle de PO dans le DSE. C'est un sujet dont il faut que PiPa s'empare rapidement pour dissiper les malentendus. |
| 12/08/2025 - 10:00 - Tuesday |
false |
|
Tenue du meeting de convergence PFE-SAE avec JeCh, AlLe, PiBo, PiPa, EdCr et PaBo |
| 12/08/2025 - 08:00 - Tuesday |
false |
|
Grosse réflexion sur l'état de maturité de l'équipe SAE suite aux couacs récurrents et ce malgré une embellie
certaine : l'équipe semble très vite retomber dans ses travers et notamment en matière d'aptitude à gérer le
travail qui reste à faire (recul de la release Statham à une date non-définie) et donc tensions entre SM et PM ...
les engagements ne sont pas de véritables engagements à ce stade. Retrait personnel du Manifeste SAE. |
| 11/08/2025 - 15:00 - Monday |
true |
|
Stabilisation SAE : toujours pas de monitoring de ce qui se passe sur le réseau (entre le front-end et le back-end). Il
en résulte que lorsque quelque chose ne fonctionne pas comme attendu, c'est le SAE qui est mis en cause. La réalité
est qu'on ne sait pas si c'est SAE qui est à la faute, le réseau, ou le serveur. C'est un élément mentionné depuis
le mois de mars 2025 et qui n'est toujours pas pris en compte. Quand le sera-t-il ? |
| 11/08/2025 - 14:00 - Monday |
true |
|
Stabilisation Data : il n'y a plus de mention des efforts de stabilisation sur la partie "Data" et "Bases de données"
dans le projet SAE et ce malgré le fait que nous ayons annoncé ce travail. Il semblerait que pour l'équipe, l'effort
de stabilisation est terminé (ou presque). Situation critique. |
| 11/08/2025 - 11:53 - Monday |
true |
Démo - checklist |
Nécessité de disposer d'une checklist pour les démos. Voici une proposition de sujets à améliorer:
1. Disposer
d'une checklist
2. Descendre les stores
3. Enregistrer le meeting pour ceux qui n'ont pas pu être présents
4. Stocker
l'enregistrement à un endroit standard
5. Couper automatiquement les micros dans le setup de meeting
6. Introduire
l'objectif de la démo (ce qui a été fait comparé à ce qui était prévu)
7. À gauche, à droite, en haut, en bas
(pas "ici", pas "onglet", pas "il a généré" mais "on modifie ceci ou cela, on appuye sur le bouton "Envoyer, etc."
...)
8. Pas trop d'explications techniques mais parler des résultats pour l'utilisateur
9. Personne du business n'est
venu physiquement (19 personnes physiquement présentes vs. combien de personnes en Teams ... 9?)
10. Excellent les
cercles souris pour bien montrer où cela se passe à l'écran
11. Pas de meeting dans le meeting
12. Demo Etiquette
13.
Faire article concernant notre première "Sam présente"
14. Bug lignes pré-encodées ?
15. Certains queries sont
encore lents (service matériel)
16. Donner le nom des KU qui ont demandé des choses (nous ajuster à leur ego)
17.
Plus d'humour
18. Organiser une réunion pour comprendre ce qu'on fait pour les optimisations data
19. Si plus de
questions, faut une conclusion
20. Article sur SAM Central pour la gestion des demandes
21. Survey de satisfaction démo
+ satisfaction SAE
22. Pour éviter les surprises, il faut séparer demo et review
23.
|
| 08/08/2025 - 11:14 - Friday |
true |
SAE : rappel cycle #3 et 4 |
Nécessité de rappeler ma demande antérieure de disposer d'une vue de ce qui est dans le pipeline :
Il me fut
répondu ... la semaine prochaine mais j'ai quand même encore dû revenir à la charge. Il me semble qu'on ne s'engage
pas assez ou qu'on oublie des choses. Serait-ce parce que l'équipe a trop à faire en même temps
?
________________________________________
De : BOENS Patrick
Envoyé : vendredi 8 août 2025
11:14
À : KEINBORG Michael ; NAVEZ Vincent
Cc : CRECIUN Eduard
Objet : Suite de Transporteurs
Hello Les amis,
Je vous ai contacté dans la semaine du 21
juillet en vous demandant de vous pencher sur la liste des features que vous voudriez voir ajoutés à Transporteurs en
cycle 3 et 4.
Le cycle 3 va jusqu’au 26/09. Le cycle 4 commence le 29/09 et se termine le 26/12 (ou même avant
suivant les congés que prennent nos troupes).
Il ne s’agit pas de vous engager sur un contenu, mais simplement
d’y réfléchir et d’essayer de découper cela déjà en releases potentiels. Donc … c’est juste un travail
préparatoire.
Quand pensez-vous pouvoir me donner une première liste de fonctionnalités que vous souhaitez apporter
?
Bien à vous,
Patrick
|
| 08/08/2025 - 10:00 - Friday |
true |
Vis ma vie |
Compte-rendu positif de la visite "Vis ma Vie" ...
De : BECATTINI Jefferson
Envoyé :
vendredi 8 août 2025 10:09
À : NAVEZ Vincent ; BOENS Patrick ; CRECIUN
Eduard ; KEINBORG Michael ; MARCOS Sara
Cc :
BOUCHAT Pierre-Michel ; PAELINCK Pierre ; POCHET Christian
; HACHEZ David
Objet : Compte rendu visite Hainaut &
Luxembourg
Bonjour à tous,
Dans le cadre de notre initiative "vis ma vie", nous avons effectué deux visites cette
semaine : dans la BU Hainaut et dans la BU Namur-Luxembourg, au dispatch de Libramont.
De manière générale,
l’initiative a été très bien accueillie et nos utilisateurs étaient ravis de nous voir venir à leur rencontre.
Voici donc un petit compte-rendu de nos deux visites :
Dispatch de Mons / BU Hainaut
Personnes présentes : Gaspar
Charlier (Dev), Nicolas Duvivier (Test), Vincent Navez (PO), Becattini Jefferson (UX)
Dispatcheurs rencontrés : Nid
M'Barek Rachid, Loïc Blaze, Daniel Seine, Christophe Hecq
La journée s’est très bien passée, avec beaucoup
d’échanges avec le métier. Les dispatcheurs étaient ravis de nous voir et de rencontrer les personnes derrière
sam. Loïc avait préparé une grosse liste de petits soucis et bugs qu’il a pu partager avec Nicolas et Gaspar.
Outre
les problèmes restants (le souci de son à la réception des alertes reste le plus problématique), ils sont très
contents de la stabilité et des performances retrouvées du SAE.
Malgré le calme des vacances, l’équipe a pu voir
à quoi ressemble le quotidien d’un dispatcheur, le stress que cela peut engendrer et la responsabilité qui leur
incombe.
Dispatch de Libramont / BU Namur-Luxembourg
Personnes présentes : Solange Mordant (Dev), Vincent Navez (PO),
Becattini Jefferson (UX)
Dispatcheurs rencontrés : Sébastien Pisvin, Samuel Martinot, Christophe Mertz
Cette visite
nous a permis de prendre un premier contact concret avec Sébastien Pisvin, qui remplace Christophe Kaiser à la
direction du dispatch et du contrôle.
Cela nous a donc permis de créer un lien important avec lui, et de renforcer les
relations et la confiance que nous avions initiées avec Christophe Kaiser ces dernières années.
Encore une fois,
l’initiative a été accueillie avec beaucoup d’enthousiasme. On sent le plaisir de nos utilisateurs à partager
leur quotidien et leurs expériences, afin de construire un meilleur outil ensemble.
Dans tous les cas, les retours
étaient très positifs : quelques bugs mineurs sur lesquels nous travaillons déjà, mais globalement, ils sont très
satisfaits de sam.
Petit point néanmoins
Les dispatcheurs un peu plus seniors continuent de travailler avec Géoloc et
CCS (Géoloc par habitude et CCS comme solution de secours, car considérée comme bien plus fiable).
Dans certains cas,
ils utilisent TECfinder afin de mieux visualiser les lignes et les bus qui y circulent.
Une bonne discussion en a
découlé, avec de nombreuses opportunités UX/UI identifiées.
Conclusion
Continuons cette initiative : nos
utilisateurs y sont réellement sensibles. En plus de renforcer nos liens, cela nous permet d’identifier ce qui ne va
pas, ou de découvrir de nouvelles opportunités pour faire de notre SAE un programme efficace, et surtout
irremplaçable aux yeux de nos utilisateurs.
Belle journée à toutes et à tous,
|
| 08/08/2025 - 00:00 - Friday |
false |
|
Journée lénifiante passée à rattraper les emails non-lus (trop ... beaucoup trop d'emails, ce qui nous congestionne)
: lecture, réponse, suivi. Identique à certains jours précédents. Suis arrivé à passer de 1152 mails non lus à
812. Ce qui pollue le plus ce sont les mails qui ne sont que des acceptations ou refus de meeting et les mails où on
est en CC juste pour se couvrir.
|
| 07/08/2025 - 15:45 - Thursday |
false |
Daily Scrum : un doc |
Face à quelques petits trous dans la raquette, je propose un document qui explique le déroulé du Daily Scrum et le
danger de procéder seulement avec les trois questions de base.
De : BOENS Patrick
Envoyé : jeudi 7 août 2025
15:45
À : CRECIUN Eduard ; KEINBORG Michael ; NAVEZ Vincent
; DUVIVIER Nicolas ; BECATTINI Jefferson
Cc : PAELINCK Pierre ; BOUCHAT Pierre-Michel
Objet : Daily Scrum
Bonjour les amis,
Je vous invite à prendre connaissance de ce
nouveau document qui parle du Daily Scrum : daily scrum.docx
Je trouve que ce document est important surtout dans la
partie « Le Taskboard parle » : vous y trouverez un problème qui impacte pas mal le fonctionnement des équipes
agiles … ces US dont on ne parle pas parce que personne n’est occupé à y travailler.
L’idée c’est que vous
formalisiez votre manière de travailler et que vous compreniez l’importance d’afficher le taskboard lors de vos
dailies.
Bien à vous,
Pat
|
| 07/08/2025 - 14:30 - Thursday |
false |
|
Staff Management Meeting : nous n'avons toujours aucun suivi correct de la demande d'Eduard à pouvoir disposer d'un
outil pour la génération automatique des Release Notes (pour notamment désencombrer MiKe) ni sur l'octroi d'un budget
annuel de ±500€ pour prendre deux abonnements IA qui pourraient être utilisés par l'équipe de développement pour
les aider dans la génération et la documentation de code. |
| 07/08/2025 - 12:21 - Thursday |
false |
La bonne démo : un petit manuel |
De : BOENS Patrick
Envoyé : jeudi 7 août 2025 12:01
À : DUVIVIER Nicolas ; CRECIUN Eduard
; KEINBORG Michael ; NUNKOVICS Jérémy ;
NAVEZ Vincent ; BECATTINI Jefferson
Cc : PAELINCK Pierre
; BOUCHAT Pierre-Michel
Objet : Aide à la tenue d'une
démo
Hello à tous,
J’ai fait le document « La bonne démo » pour vous aider à réaliser … une bonne démo :
La bonne démo.docx
Je sais que c’est tout un métier ! C’est une partie du métier d’évangéliste dont l’IA
nous dit ceci :
Le métier d’évangéliste dans une société de haute technologie est un rôle hybride et
stratégique, centré sur la promotion, l’adoption et la diffusion d’innovations technologiques aussi bien à
l’externe (clients, partenaires, communautés de développeurs) qu’à l’interne (collaborateurs,
directions).
Missions principales
• Promouvoir la technologie ou la vision de l’entreprise auprès de différents
publics (développeurs, étudiants, influenceurs, clients, médias) par des conférences, articles, blogs, webinaires,
démonstrations et événements.
• Créer et animer des communautés autour de la marque ou d’une technologie-clé,
en favorisant l’engagement et la co-création.
• Expliquer et vulgariser les bénéfices de technologies souvent
complexes, pour convaincre et rassurer sur leurs usages ou leur adoption.
• Agir comme expert référent et point de
contact incontournable pour les questions relevant de la technologie défendue.
• Faciliter la transformation digitale
des organisations, en accompagnant les équipes dans le changement, et en les sensibilisant aux enjeux des nouveaux
outils.
• Participer à la veille technologique et anticiper les tendances afin d’orienter le développement et la
mise en avant de solutions innovantes.
Compétences requises
• Maîtrise technique et compréhension approfondie du
produit, service ou technologie promue.
• Excellentes capacités de communication (rédaction, présentation orale,
storytelling) et de pédagogie.
• Leadership et charisme pour inspirer, entraîner et fédérer autour d’une
vision.
• Capacité à réseauter et à animer des communautés, en ligne comme lors d’événements
physiques.
• Agilité entre méthodes marketing, développement logiciel, et stratégie digitale.
Importance
stratégique
L’évangéliste joue un rôle essentiel dans la démocratisation des innovations et la construction
d’une base d’utilisateurs fidèles. Il agit comme un ambassadeur et un guide lors des phases de transformation ou de
lancement d’une nouvelle solution, incarnant la vision de l’entreprise et contribuant activement à son rayonnement
et à l’adoption rapide de ses technologies.
En résumé, dans la tech, un évangéliste n’est pas seulement un
promoteur, mais aussi un leader d’opinion, un formateur et un catalyseur du changement technologique, au croisement du
technique, du marketing et de la communication.
Bien à vous,
Pat
|
| 07/08/2025 - 12:09 - Thursday |
false |
Retard Statham |
Réponse d'Eduard concernant le retard (et puis ma réponse):
De : CRECIUN Eduard
Envoyé :
jeudi 7 août 2025 12:01
À : BOENS Patrick
Objet : RE: IMPORTANT et URGENT ... RE: Retard
release Statham
Salut Patrick,
J’ai fait un point avec l’équipe.
Il y a plusieurs points qu’il faut prendre
en compte :
1. Ajouter les utilisateurs transporteurs --> CDS (en cours, pas encore fait je dois les relancer )
2. Ouvrir accès vers le monde externe --> Infra (rendez-vous cet après midi pour un premier test) c’est comme
prévu
3. Mettre en prod SAE :
a. Corrections derniers mis en commun
b. Validation des données reçues bcp de
doublons et incohérences. Equipe SAP est informée et selon elle c’est « normal » voir le mail joint.
c. Corrections des derniers bugs fonctionnels : droits d’accès / véhicules filtrés dans l’historique
4. Test
smoking : 1 jour
5. Tests fonctionnels : quelques jours
a. Intégrité des données
b. Fonctionnalités
6. Test avec
3 utilisateurs : ext.picavet@gmail.com, ext.cintra@gmail.com ok
Prochaines dates :
- GO/Nogo Mercredi 13.
o Le
13/08 c’est trop court pour
• tester / corriger
• Disponibilités des gens, les personnes suivantes sont en
congé :
• Bérenger (12-> 25) / Vincent N (12-25), / Nicolas F.( 26-08 : 15-08)
- Sur base de tout ça je propose de
faire le GO/NoGo la semaine du 19/08
- Une MEP qui suit cette Go/NoGo à mettre dans la semaine du retour de Vincent
N. que ce soit pour la démo et/ou communication
Comme discuté, le CCS est en parallèle (par Quentin) et cela
n’impacte en rien le livrable des transporteurs.
Pour les Burndown nous avons besoin d’un PO qui soit formé
pour cela et qui gère les tickets pour gérer les estimations et priorités.
Bat,
Eduard
De : BOENS Patrick
Envoyé : jeudi 7 août 2025 12:09
À : CRECIUN Eduard
Objet : RE:
IMPORTANT et URGENT ... RE: Retard release Statham
Ouais … mais alors fallait pas s’engager ! Il fallait être plus
prudent et mieux estimer toutes les tâches.
Je sais … je suis chiant.
Deux choses à faire et les faire de TOUTE
URGENCE :
1) Refaire l’horaire SAE (plan de releases) et replanifier « Statham » : plus d’erreur cette
fois-ci
2) Mettre une ou deux releases après Statham : il faut au moins une release pour la fin du mois de septembre
(choix des sujets à votre discrétion) … et donc de mettre cela dans le prochain horaire SAE !
De surcroît, il faut
former TOUTE L’ÉQUIPE à l’utilisation des estimations : pas seulement le PO ! Si vous ne vous y collez pas, on ne
pourra jamais faire des estimations correctes. Il est indispensable de gagner en expertise sur les story points et le
calcul de la vélocité.
Allez … Rome ne s’est pas construite en un jour ! 😉
Bien à toi,
Pat
|
| 07/08/2025 - 00:00 - Thursday |
false |
|
Journée lénifiante passée à rattraper les emails non-lus (trop ... beaucoup trop d'emails, ce qui nous congestionne)
: lecture, réponse, suivi. Identique à la veille |
| 06/08/2025 - 15:23 - Wednesday |
true |
Problèmes de connexion - heartbeat |
Les problèmes de connexion nous mangent !
De : BOENS Patrick
Envoyé : mercredi 6 août 2025 15:23
À : NAVEZ Vincent
; CRECIUN Eduard ; KEINBORG Michael ;
YPERSIEL Bastien
Cc : PAELINCK Pierre
Objet : Problèmes de
connexion / authentification
Hello tout le monde,
Oui … nous devons être de bon compte : lorsqu’on ne peut plus
se connecter à SAE, c’est bien un problème SAE même si la cause est l’infra. C’est la raison pour laquelle je
plaide depuis 3 mois pour disposer, en SAE, d’un mécanisme de « heatbeat » et quand on ne reçoit plus de réponse
« oui, je suis vivant », on devrait tirer l’alarme : je parle vraiment d’alarme comme dans les films !
Par
contre, dire devant tout le monde que c’est « quand même du SAE/PFE » ne me semble pas idoine en « public ». Si
c’est dit en « privé », c’est un autre signal.
Alors … quand allons-nous mettre ce mécanisme de heartbeat en
place ? C’est inacceptable que ce mécanisme n’existe pas dans une application critique.
Bien à
vous,
Patrick
Réponse de Michael :
De : KEINBORG Michael
Envoyé : mercredi 6 août 2025
15:31
À : BOENS Patrick ; NAVEZ Vincent ; CRECIUN Eduard
; YPERSIEL Bastien
Cc : PAELINCK Pierre
Objet : RE: Problèmes de connexion / authentification
De notre coté nou venons de mettre
en place un heartbeat en dev depuis la semaine derniere, il est actuellement sur dev mais il reste interne a SAM ,Mais
il nous est facile d envoyer un signal vers une url quelconque pour faire sonner l alarme et faire echo
Réponse de
ma part à la réponse de MiKe :
Merci beaucoup ! Ce mécanisme devrait être mis en production le plus rapidement
possible car … ce mécanisme est fondamental et critique pour garantir la disponibilité, la fiabilité et la
sécurité d’architectures distribuées. Sa défaillance peut entraîner des interruptions de service, des pertes ou
corruption de données, et compromettre la continuité des processus métier et c’est exactement ce qui se passe ici.
Au demeurant ce ne sont pas nos utilisateurs qui doivent nous informer d’une perte de connexion : c’est à SAE de le
leur communiquer. 😉
Merci.
Patrick
|
| 06/08/2025 - 14:34 - Wednesday |
true |
Retard Statham |
J'apprends par mail que la release Statham aura du retard:
De : KEINBORG Michael
Envoyé :
mercredi 6 août 2025 14:34
À : NAVEZ Vincent ; BOENS Patrick ; CRECIUN
Eduard
Objet : Retard release Statham
Hello,
Désolé de vous dire que transporteur a pris
un peu de retard.
Nous avons un peu sous estimé la charge de travail de finalisation du merge de l epic transporteur
sur la branche de DEV.
Il reste des petits coups de tournevis a donner ce qui postpose aussi la phase de test.
Nous
devons revoir le calendrier de mise en production et
Reculer de 2 semaine la mise en production de statham.
Mais cela
ne met pas en peril le décommissionnements CCS puisque une partie de l'équipe travail actuellement en parallèle sur
les features CCS.
|
| 06/08/2025 - 13:17 - Wednesday |
false |
G4S |
Interpellation d'Eduard:
De : CRECIUN Eduard
Envoyé : mercredi 6 août 2025 13:17
À :
BOENS Patrick
Objet : RE: Urgent et important: Réunion TEC6 - G4S Gestion du futur SMS
d'alarme
Ok je vois.
Ce qui m’intéresse maintenant c’est
1. Correspondances bus-bus : SAM ou Hastus ? (jai un
point ce mardi 12 aout)
2. G4s (Brabant) – solution secours GSM : on renvoie sur GSM ou intègre avec la solution
Horus de G4s ?
3. RingRing : tous les dispatch sur RingRing ?
Bat,
Eduard
|
| 06/08/2025 - 09:41 - Wednesday |
true |
Prolongement certificat Xavier Moreau |
De : MOREAU Xavier
Envoyé : mercredi 6 août 2025 09:41
À : DUCHATEAU Dimitri
; FORGET Nicolas ; POCHET Christian
Cc
: GOBERT Laurence ; BOENS Patrick
Objet : Absence pour raison de
santé
Bonjour ,
Apres consultation de mon médecin traitant ce jour, je suis prolongé jusqu' au 12/09/2025
minimum.
Merci pour votre compréhension.
Bien à vous,
Xavier
|
| 06/08/2025 - 00:00 - Wednesday |
false |
|
Journée lénifiante passée à rattraper les emails non-lus (trop ... beaucoup trop d'emails, ce qui nous congestionne)
: lecture, réponse, suivi. |
| 04/08/2025 - 17:42 - Monday |
true |
Préfiltrage des demandes en souffrance |
De : LEURIDENT Christophe
Envoyé : lundi 4 août 2025 17:42
À : BOENS Patrick
; POCHET Christian ; CORDI Vincent ; PAISSE
Daniel ; ROBERT Xavier ; PRÉVOT Rémy ; LEPLAT
Arnaud ; FORGET Nicolas ; LEFEBVRE Alexis
Cc
: NAVEZ Vincent ; BOUCHAT Pierre-Michel
Objet : RE: Demandes en
souffrance
Merci Patrick.
En parcourant la liste, il me semble qu'il y a un tri à faire entre les demandes en lien
avec le PE (prioritaires) et les autres.
Bien à toi,
Christophe Leurident
|
| 04/08/2025 - 14:00 - Monday |
false |
|
PFE Sprint Review : L’objectif de cette réunion est, à la fin de chaque sprint, de faire une petite revue des
développements PFE réalisés et éventuellement quelques démonstrations. Cette réunion a lieu toutes les trois
semaines, au début du nouveau sprint. HW, PjM et PM sont facultatifs mais bienvenus.
La Review a porté sur les
deux releases faites par PFE, la release 2.1.5 : gros release après 1 an de modifis et la release 2.2.0 : pause
sanitaire le 29/07.
Il a été suggéré de demander à Christian Pochet l'accord de pouvoir faire des mises en
production quand on le souhaite (on demand) pourvu qu'on puisse l'assurer du strict respect de la procédure de MeP (le
processus est documenté mais n'a pas encore été validé -- et peut-être doit-il être adapté -- par l'équipe PFE)
(travail pour PiPa). Peut-être faudra-t-il quand même disposer d'un meeting de Go/No Go ? aussi à prendre par PiPa
(Pierre Paelinck).
L'équipe a précisé qu'elle utilisait un système sémantique de versioning (SEMVER)
rapidement documenté dans la conversation du meeting et qu'elle pratiquait par "Canary Release" aussi rapidement
documenté dans la conversation Teams.
Ensuite, le meeting s'est rapidement transformé en blabla, certes
intéressant, mais qui n'a pas servi à établir des actions concrètes ce qui les rend de facto inutiles.
|
| 04/08/2025 - 11:28 - Monday |
true |
Bascule LV - Daily Prayers |
Nous apprenons de Sara qu'Olivier Stassart n'envisage pas de bascule entre le 04/08 et le 14/08. Voici le mail de Sara
:
De : MARCOS Sara
Envoyé : lundi 4 août 2025 11:28
À : BOENS Patrick
; BECATTINI Jefferson ; HACHEZ David ;
NAVEZ Vincent
Cc : FORGET Nicolas
Objet : Basculement
LV
Hello,
Pour info, j'ai eu meeting ce matin avec Olivier S. , il n'envisage pas de basculement vers sam en
septembre...
• Manque d'effectif.
• Période de rentrée scolaire.
Bàv,
Par la suite ... j'envoie le mail
qui suit:
De : BOENS Patrick
Envoyé : lundi 4 août 2025 11:53
À : MARCOS Sara
; FORGET Nicolas ; BECATTINI Jefferson ;
NAVEZ Vincent ; HACHEZ David ; DUVIVIER Nicolas
; CRECIUN Eduard ; KEINBORG Michael
Cc :
POCHET Christian
Objet : RE: Basculement LV
Importance : Haute
Alors … cela n’a pas de
sens de nous acharner sur la liste MoSCoW car, d’ici qu’ils passent à SAE, il y aura tellement de modifications
qu’ils nous sortiront autre chose pour ne pas y aller.
Dès lors, je suggère un changement de stratégie :
1) On ne
s’occupe plus du tout d’eux
2) Quand on fait une release, on vise à obtenir le GO/NO GO de LV
3) On multiplie les
releases entre maintenant et fin septembre en réduisant le scope de chaque release (on met en production de petites
avancées – notons que c’est comme cela qu’on devrait procéder de toute façon). Cela présuppose qu’on soit en
capacité de promouvoir de petites releases (réduction du travail manuel)
Qu’en pensez-vous ?
Par ailleurs, nous
allons devoir officialiser cette position de LV et en faire part, via une communication indépendante, au CoPil (et plus
si … affinités). Je dois dire que je trouve cette situation un peu « honteuse » car LV pouvait commencer les tests
dès le 07/07 conformément à ce qui était prévu.
Patrick
PS : il y a une « lesson learned » : pour LV,
Juillet-Août est une période où peu d’avancements peuvent être effectués. Peut-être est-ce dû à une
conjonction de circonstances ?!?
|
| 04/08/2025 - 10:57 - Monday |
true |
Bascule LV - Daily Prayers |
Essai d'améliorer le fonctionnement et le suivi de ce qui est à faire pour LV:
Hello Nicolas,
Juste pour être sûr
qu’on partage les mêmes objectifs :
1) Le meeting doit être court et être centré sur des sujets très
circonscrits
2) Chaque meeting doit être ponctué par une action bien précise
3) L’action doit être reprise le
lendemain
L’idée est de fonctionner en « clean room » : on entre dans une pièce et quand on la quitte, elle est
propre.
Au final, on a parcouru toutes les pièces de la maison … et, ultimement, on a une date de bascule laquelle
doit être vérifiée avec l’équipe de dev, ViNa, JeCa, et avec Sara et David (équipe Change).
Désolé de
répéter tout cela – je ne veux pas être sur le dos de qui que ce soit – mais c’est juste parce que cette
bascule est hyper-importante. Je sais que tu fais au mieux.
Bien à toi,
Patrick
|
| 04/08/2025 - 10:08 - Monday |
true |
Fix suite à la mise en prod d'Atlas |
Message de Michael Keinborg sur "Coin Café" relatif à
YPERSIEL Bastien
Fix pour les exports (prod) et fix pour les
qualifications de ticket (staging pour l'instant)
>>>
Oui le fix pour les exports a été tes vite déployé la
semaine dernière
<<< |
| 04/08/2025 - 09:18 - Monday |
true |
Place de ViCo à son retour |
Merci Patrick pour le feedback.
C’est un point que Nicolas et moi devrons prendre en charge au retour de Vincent. En
tout cas, je suis satisfait de ce qui est en train de construire et j’aimerais donc que l’on continue dans ce sens.
Quel est ton sentiment par rapport à son retour ?
As-tu du feedback de l’équipe sur cette question.
Bien à
toi,
Christian
Rappel = mail que j'ai envoyé vendredi 01/08 ...
De : BOENS Patrick
Envoyé : vendredi 1 août 2025 11:23
À : POCHET Christian ; FORGET Nicolas
Objet : For your eyes only ...
Voici un extrait de ce qui a été exprimé hier par
Christophe et Rémy en fin de CoPil :
« ChLe : Je vous pose la question, mais je fais une parenthèse. Que se
passe-t-il quand Vincent Cordi revient ? Parce que, évidemment, les choses ont beaucoup changé en son absence. Je dois
en parler à Patrick, à Christian, par rapport à l'organisation du projet qui s'est mise en place. J'imagine que ce
sera en bonne intelligence. RePr : Si je peux apporter un petit commentaire complémentaire, c'est que jusqu'à
présent, les copils étaient parfois très compliqués à suivre. C'est pas toujours évident. La remise en question de
l'IT et du fonctionnement, pour moi, transparaît jusqu'au copil. Ça paraît beaucoup plus clair et beaucoup plus
dégagé. J'ai plus le sentiment qu'on sait ce qu'on fait maintenant. C'était pas toujours le cas, c'était parfois un
peu obscur. Sans vouloir critiquer personne. »
Je ne sais pas comment on va manœuvrer. Je m’en remets à
vous.
Bien à vous,
Patrick
|
| 04/08/2025 - 08:46 - Monday |
true |
State of Charge |
Intégration du SoC dans le cycle Mark Twain (cycle #3) : réponse de MiKe |
| 02/08/2025 - 14:33 - Saturday |
false |
Hackathon |
Implication du Change (David et Sara) dans une aide au hackathon |
| 01/08/2025 - 14:35 - Friday |
false |
|
PROPOSITION DE HACKATHON
====================
Les amis,
Je voudrais partager une initiative qui me tient à cœur :
organiser un hackathon interne autour de notre backlog de demandes non traitées (Liste des dossiers)
L’idée est
simple et pragmatique : former des binômes composés d’un développeur et d’un représentant métier, puis confier
à chaque équipe un sujet issu de notre backlog. L’objectif ? Prototyper en deux jours une solution concrète, en
s’appuyant autant que possible sur l’IA pour accélérer la réalisation et stimuler la créativité.
Voici les
grandes lignes du format :
• Jusqu’à 8 équipes de 2 personnes (dev + business)
• Chaque équipe choisit un
sujet parmi une présélection des demandes issues du backlog de nos demandes non traitées (présélection par ViNa,
EdCr et MiKe … et membres du CoPil)
• Deux jours pour concevoir un prototype, avec recours encouragé aux outils
d’IA pour le prototypage rapide
• Présentation finale : 10 minutes de pitch par équipe, le deuxième jour
après-midi
Ce hackathon vise à :
• Favoriser la collaboration entre profils techniques et métiers, pour des
solutions ancrées dans le réel
• Au travers des prototypes les plus aboutis, choisir les sujets qui sont les plus
porteurs de valeur pour notre Business et nos utilisateurs
• Améliorer notre image auprès du Business et nos
utilisateurs, non pas par du « déclaratif » mais par des faits, des actions, par du concret
• Réduire notre
backlog de demandes non-traitées (et commencer à mesurer objectivement notre lead time de backlog – temps qui passe
entre l’entrée d’un sujet dans notre backlog et sa sortie, entre « TODO » et « DONE »)
• Explorer le
potentiel de l’IA dans nos processus de prototypage afin de l’industrialiser
• Créer une dynamique collective et
ludique autour de notre capacité à traiter du « CHANGE » (capacité à absorber des nouveautés)
Je suis convaincu
que ce format sera à la fois utile, motivant et formateur pour chacun d’entre nous, c’est-à-dire nos quatre
catégories de parties prenantes : notre Business, notre Management, nos utilisateurs et … nous-mêmes !
Au plaisir
d’en discuter avec vous et de lancer cette aventure ensemble … pour le cycle 4 de 2025 (du 29/09/2025 au
26/12/2025). Votre participation active est vivement souhaitée.
Vous pouvez déjà me faire part de vos remarques et
suggestions. 😉 Si vous êtes OK avec la démarche, utilisez les boutons de réponde au mail (et s’ils ne
fonctionnent pas … envoyez-moi une réponse individuelle)
Bien à vous,
Patrick
|
| 01/08/2025 - 13:30 - Friday |
false |
|
Feedback CoPil SAM à l'équipe |
| 01/08/2025 - 11:36 - Friday |
true |
Processus de mise en production générique |
De : BOENS Patrick
Envoyé : vendredi 1 août 2025 11:36
À : CRECIUN Eduard
; NAVEZ Vincent ; KEINBORG Michael ;
PAELINCK Pierre ; DUVIVIER Nicolas ; LEFEBVRE Alexis
Objet : IMPORTANT : Votre approbation du document est requise
Importance :
Haute
Hello,
Vous devez approuver ou rejeter le document processus générique de mise en production SAE.docx
Pour
approuver le document, je vous propose de mettre la date à laquelle vous approuvez le document, et un petit paraphe
dans la colonne signature.
Bien à vous,
Patrick
PS : je pense que si la procédure s’applique à DSE, le nom du doc
devrait le mentionner au lieu de SAE
|
| 01/08/2025 - 11:25 - Friday |
false |
|
Tickets Fresh Service en souffrance dans SAE selon Bastien
AB3325 INFOS ETIQUETTE NOK + BUS GRISE MAIS LOCALISE
#INC-106042
Request for Daniel SEINE : Systemes Embarqués - SAE - Systèmes Embarques -SAE
#SR-105978
Request for
Daniel SEINE : Systèmes Embarqués - SAE - Systèmes Embarques -SAE
#SR-105977
AB101151 INFOS ETIQUETTE NOK
#INC-106043
Request for Daniel SEINE : Systemes Embarques - SAE - Systèmes Embarques -SAE
#SR-106044
Request for
Daniel SEINE : Systemes Embarques - SAE - Systèmes Embarques -SAE
#SR-104978
Request for Christophe KAISER : Systemes
Embarqués - SAE - Systèmes Embarqués -SAE
#SR-104636
rafraichissement page SAM #INC-105027
localisation eronee
#INC-105037
Request for Daniel SEINE : Systemes Embarques - SAE - Systèmes Embarqués -SAE
#SR-105228
Request for
Daniel SEINE : Systemes Embarques - SAE - Systèmes Embarqués -SAE
#SR-105695
SAM - Encodage deviation
#INC-105920
INFO ETIQUETTE AB3315 NOK #INC-105934
Request for Daniel SEINE : Systemes Embarques - SAE - Systèmes
Embarqués -SAE
#SR-105545
Correspondance Train-bus #INC-105942
AB3319 INFO ETIQUETTE NOK #INC-105965
AB3537 INFOS
ETIQUETTES INCOMPLETES ET FAUSSES #INC-105970
AB3857 INFO ETIQUETTE NOK #INC-105968
AB3890 INFOS ETIQUETTES NOK
GEOLOCALISATION NOK #INC-105971
Request for Daniel SEINE : Systemes Embarques - SAE - Systèmes Embarqués
-SAE
#SR-105691
Il y en a 20 qui sont en ouvert pour le mois de Juillet et Aout 2025
|
| 01/08/2025 - 09:30 - Friday |
false |
|
Synchro NextG |
| 31/07/2025 - 15:00 - Thursday |
false |
|
CoPil SAM : excellent
COPIL-SAM-SAE-SAM-PFE-20250731.pptx
Message à l'équipe :
Le CoPil tient à vous exprimer
toute sa gratitude pour l’ampleur du travail accompli et les efforts déployés, vous adressant ses plus vifs
encouragements, et propose, dans ce bel élan collectif d’organiser une communication visant à rassurer l’ensemble
des parties prenantes quant à la dynamique prometteuse qui anime aujourd’hui nos équipes. Ce pourra se faire après
la finalisation de la R&D du « bloc comm. » (PFE)
Bien à vous,
Patrick
PS : si vous n’avez pas accès à la
présentation, mentionnez-le moi.
|
| 31/07/2025 - 11:27 - Thursday |
true |
Taux d'incidents |
Rappel de ma demande de disposer d'un taux d'incidents pour SAM afin de traquer cette donnée que je trouve importante
pour des KPI.
________________________________________
De : BOENS Patrick
Envoyé : jeudi 31
juillet 2025 11:27
À : NAVEZ Vincent ; BECATTINI Jefferson ;
DSE.Demande
Cc : KEINBORG Michael ; CRECIUN Eduard
Objet : Historique des tickets Fresh Service
En tant que Chef de programme et, ultimement
responsable de la qualité des solutions SAE construites,
Je souhaite bénéficier d’un histogramme présentant
l’évolution des tickets Fresh Service (cf. similaire à image attachée),
Afin de pouvoir analyser la tendance
(amélioration ou dégradation) des solutions développées par l’équipe.
Critères d’acceptation :
1. Je peux
visualiser un histogramme reflétant l’évolution du volume de tickets Fresh Service sur différentes périodes (par
mois, trimestre…).
2. L’histogramme différencie les types/priorités de tickets (urgent, haut, moyen, bas,
incident, demande…).
3. Je peux facilement identifier les tendances (hausse ou baisse du nombre de tickets),
illustrées par des indicateurs visuels (flèches, pourcentages, couleurs…).
4. Le rapport met l’accent sur
l’évolution (dynamique) plutôt que sur le statut à un instant T.
5. Il est possible de filtrer ou d’exporter les
données de l’histogramme à des fins d’analyse complémentaire.
Finalement, plus tard, le 12/09 ... cette demande
a trouvé une issue heureuse via l'export de données de FreshService ce qui a permis de créer la version 0 de l'outil
dont j'avais besoin. |
| 31/07/2025 - 11:15 - Thursday |
true |
Compteurs d'utilisation : stats |
Demande de disposer de compteurs d'utilisation ...
De : BOENS Patrick
Envoyé : jeudi 31
juillet 2025 11:15
À : NAVEZ Vincent ; BECATTINI Jefferson ;
DSE.Demande
Cc : KEINBORG Michael ; CRECIUN Eduard
Objet : Stats d'usage des modules
En tant que Chef de Programme,
Je souhaite connaître
l’usage réel des modules dans l’application construite par l’équipe SAE,
Afin de pouvoir concentrer les efforts
de développement sur les modules les plus utilisés et d’identifier les modules sous-utilisés pour éventuellement
les abandonner ou, au contraire, promouvoir leur usage.
Critères d’acceptation :
1. Je peux visualiser un
rapport/bilan d’utilisation par module sur une période donnée.
2. Les statistiques présentent à la fois le nombre
d’utilisateurs et la fréquence d’utilisation de chaque module.
3. Les données sont suffisamment détaillées pour
permettre d’identifier clairement les modules prioritaires et ceux à faible usage.
4. Il est possible d’exporter
ces données à des fins d’analyse complémentaire.
Merci,
Patrick
|
| 31/07/2025 - 11:00 - Thursday |
false |
|
Préparation "Croisement" - je suis proche de pouvoir conclure |
| 31/07/2025 - 08:00 - Thursday |
false |
|
Préparation Cycle : explications dans une présentation de ce qui se passe durant la semaine de transition d'un Cycle
au suivant |
| 30/07/2025 - 11:00 - Wednesday |
false |
|
Finalisation slides CoPil prévu pour le lendemain |
| 30/07/2025 - 09:00 - Wednesday |
false |
|
Suivi pour hiérarchie organisé par Pierre Bouchat |
| 30/07/2025 - 08:43 - Wednesday |
true |
Mise en production de la release Atlas (29/07/2025) |
Question de Christian Pochet sur "Coin Café" (Teams)
>>>
Bonjour à tous, comment s'est passé la mise en production ?
Y a-t-il un retour des métiers ?
POCHET Christian:
Bonjour à tous, comment s'est passé la mise en production ? Y
a-t-il un retour des métiers ?
YPERSIEL Bastien:
Les users sont assez content de la vitesse du module alerte et du
module cartographie.
Par contre aucun export (que ce soit csv ou excel) est disponible.
Il y a aussi des options de
qualification de ticket qui manque "annulation" et "expiré automatiquement"
<<< |
| 29/07/2025 - 14:00 - Tuesday |
false |
|
Meeting NextG |
| 29/07/2025 - 13:30 - Tuesday |
false |
|
Préparation de la semaine de transition du cycle #3 au cycle #4 |
| 29/07/2025 - 13:00 - Tuesday |
false |
|
Préparation du "Croisement" (voir doute antérieur déjà exprimé) |
| 28/07/2025 - 14:30 - Monday |
false |
|
Discussion concernant le SoC : peut-on l'embarquer ou non dans la release Statham ? Réponse : oui |
| 28/07/2025 - 14:00 - Monday |
false |
|
Préparation de l'information concernant la semaine de transition (la 13ème semaine d'un cycle) |
| 28/07/2025 - 13:30 - Monday |
false |
|
Préparation du "Croisement" qui à mon avis n'aura pas lieu car ... un mois après la mise en route de "Mark Twain", je
commence à avoir de sérieux doutes sur la capacité de l'équipe à grimper en maturité sur du long terme : des
efforts courts, et parfois intenses sont possibles mais ne semblent pas possibles dans la durée (même si on en réduit
l'intensité) |
| 28/07/2025 - 13:00 - Monday |
false |
|
Réunion mensuelle avec Pierre Bouchat concernant SAM, PFE et SAE |
| 28/07/2025 - 10:30 - Monday |
false |
|
Préparation des éléments de la démo future de Atlas |
| 25/07/2025 - 08:00 - Friday |
false |
|
Dernières modifications CoPil |
| 24/07/2025 - 14:30 - Thursday |
false |
|
Réunion Staff Management |
| 24/07/2025 - 10:30 - Thursday |
false |
|
Go / No Go pour Atlas : ponctué par un NO GO |
| 24/07/2025 - 07:00 - Thursday |
false |
|
Journée majoritairement consacrée à la préparation du CoPil |
| 23/07/2025 - 14:30 - Wednesday |
false |
|
Démo Atlas |
| 23/07/2025 - 10:30 - Wednesday |
false |
|
Synchro Transporteurs pour CoPil |
| 22/07/2025 - 14:00 - Tuesday |
false |
|
Meeting NextG |
| 22/07/2025 - 10:00 - Tuesday |
false |
|
Préparation CoPil avec les différents intervenants |
| 18/07/2025 - 13:30 - Friday |
false |
|
Feedback DirEx à l'équipe SAE |
| 17/07/2025 - 16:00 - Thursday |
false |
|
Réunion staff management. Il faut voir les minutes de la réunion mais où ? |
| 17/07/2025 - 11:00 - Thursday |
false |
|
Synchro PFE et Préparation CoPil |
| 16/07/2025 - 16:00 - Wednesday |
false |
|
Interview testeur / test manager : G. Horlait |
| 16/07/2025 - 15:00 - Wednesday |
true |
|
Travail sur la DoD et DoR (présentation par JeBe) ... alors que deux documents
existaient déjà.
Impression de faire beaucoup de choses que les gens n'utilisent d'ailleurs pas
au final. Travail inutile ?
Néanmoins, ce travail de définition de DoD et DoR est considéré comme
un pas dans la bonne direction de
la rigueur exigée par la Direction. C'est une étape vers Kaizen. |
| 16/07/2025 - 12:30 - Wednesday |
false |
|
Préparation CoPil |
| 16/07/2025 - 09:00 - Wednesday |
true |
Billetique |
Message de Christian Pochet sur "Coin Café" (Teams)
>>>
Lundi, j’ai participé au copil de programme Billettique.
Petite nouveauté de gouvernance : Kelly Lacey reprend le rôle de cheffe de projet, sous le sponsorship de Stéphane
Thierry. Renaud Therry reste bien sûr toujours à la manœuvre et conserve son rôle de décideur en tant que chef de
département.
Le projet avance bien. La première version du cahier des charges est désormais prête. Nous sommes
dans la phase finale de relecture. C’est le fruit d’un travail collectif important, où chaque point de vue a été
pris en compte. La direction IT a été largement impliquée dans le processus : nous participons aux choix structurants
et faisons pleinement partie du projet.
C’est une vraie réussite en termes de positionnement. L’IT n’est pas vu
ici comme un simple fournisseur technique, mais comme un partenaire stratégique à part entière.
<<< |
| 15/07/2025 - 08:00 - Tuesday |
false |
|
Deuxième étape pour l'Espagne : indisponible toute la journée |
| 14/07/2025 - 08:00 - Monday |
false |
|
Départ en Espagne : indisponible toute la journée |
| 11/07/2025 - 14:00 - Friday |
false |
|
Interview Cédric Jardon pour Testeur et Test Manager |
| 11/07/2025 - 13:30 - Friday |
false |
|
Discussions sur la pause sanitaire entre SAE et PFE; synchronisation entre les équipes pour les dates de livraison |
| 11/07/2025 - 10:30 - Friday |
true |
|
Présentation PFE et SAE en DirEx avec VANDER PUTTEN Benoit (Benoit.VANDERPUTTEN@letec.be), Nicolas Forget et Alexis
Lefebvre.
Annonce de ce qui a été fait (Horaire SAE, Manifeste SAE, Cycle, Pause sanitaire, ...) |
| 11/07/2025 - 09:45 - Friday |
true |
|
Synchro NextG : il me semble qu'on n'avance pas ! |
| 10/07/2025 - 10:30 - Thursday |
false |
|
Interview Tester / Test Manager : Jeremy Nunkovic |
| 09/07/2025 - 13:00 - Wednesday |
true |
|
Travail de préparation (slides) pour DirEx |
| 03/07/2025 - 08:00 - Thursday |
true |
|
Préparation du manifeste SAE : toute la journée. Manifeste agile nécessaire pour meeting "Mark Twain" |
| 02/07/2025 - 15:00 - Wednesday |
false |
|
Interview d'un test manager : candidat Astek (remplacement de Guy) |
| 02/07/2025 - 08:00 - Wednesday |
true |
|
Préparation toute la journée de l'idée de hackathon pour :
1) Travailler de manière rapprochée avec le
Business
2) Vider, au moins partiellement, la liste des demandes en souffrance
3) Recours à l'IA dans le
contexte du développement
Cette préparation a consisté à produire une documentation abondante sur les objectifs
du hackathon, son organisation, ...
|
| 01/07/2025 - 10:00 - Tuesday |
false |
|
Discussion sur les brown bag sessions : parfaitement inutile car blabla indescriptible. Les équipes ne sentent
d'ailleurs pas le besoin d'avoir ce genre de sessions car elles connaissent l'Agilité. Coup dans l'eau. |
| 30/06/2025 - 10:00 - Monday |
true |
|
Meeting importantissime : Mark Twain (ils ne savaient pas que c'était impossible alors ils l'ont fait) de 10h00 à
12h00. Gros doutes de la part des responsables Change (David et Sara) sur la capacité et la volonté de l'équipe à
s'engager. 2 meeting de préparation en amont. |
| 30/06/2025 - 08:00 - Monday |
false |
|
Début du cycle 3 : du 30/06/2025 au 26/09/2025 |
| 30/06/2025 - 00:00 - Monday |
false |
|
Article SAM Central : Phénix |
| 20/06/2025 - 16:15 - Friday |
true |
Premier bloc comm 4G |
Message de Nicolas Forget sur "Coin Café" (Teams)
>>>
Et pour finir la semaine, l'équipe SAM vient de m'envoyer une
photo du premier bloc de communication 4G de la PFE. Cette photo matérialise une étape importante pour stabiliser le
produits que nous avons conçu. Bien évidemment, il ne s'agit que d'une étape puisqu'il faut encore réaliser la
production de l'ensemble et en équiper les bus. Mais je veux croire qu'elle nous illustre le trajet parcouru pour
fiabiliser SAM, ce qui reste un de mes objectifs prioritaires !
Merci à tous ceux qui se sont impliqués pour que
cette photo soit possible et merci à tous pour le travail qui sera à réaliser pour en équiper tous nos bus !
<<< |
| 20/06/2025 - 12:48 - Friday |
true |
Département IT global : salon UITP |
Message de Nicolas Forget sur "Coin Café" (Teams)
>>>
Début de semaine, avait lieu le salon de l'UITP, l'union
internationale du transport public. Ce salon rassemble tous les acteurs du monde du transport, que ce soit les
opérateurs, les constructeurs ou les vendeurs de logiciels et intégrateurs. La caricature serait de dire que le salon
est un mix du salon de l'auto et de Batibouw, orienté vers le transport public. Une délégation du TEC était
présente, avec une grande partie du CoDir, Vincent Urbain étant resté à Namur pour faire tourner la maison.
Christian et moi représentions l'IT.
Nous avons pris le temps de rencontrer une série de fabricants, principalement
orientés vers les SAE, PFE et vers la billettique. Les rencontres nous ont permis de retirer plusieurs enseignements
intéressants :
Nous n'avons pas à rougir de la solution que nous avons construite. Même si elle ne reprend pas
toutes les fonctionnalités des produits du marché, toutes les grandes fonctionnalités nécessaires dont nous avons
besoin sont implémentées de manière très similaires sur ces produits ;
L'information voyageur est généralement
intégrée à la solution SAE, nous en avons fait un projet séparé ;
Le marché des SAE est très mature, avec
plusieurs acteurs en relation avec plusieurs opérateurs avec plusieurs philosophies différentes ;
Nous sommes à la
dernière ligne droite de la définition du trajet billettique et les discussions tournaient fort autour des derniers
détails de notre stratégie.
La visite des différents stands nous a aussi donné une bonne vision de l'avenir du
transport public qui passera par l'électrique (pas un seul bus thermique sur les stands) et par la conduite autonome
dont plusieurs véhicules et prototypes étaient présentés sur les stands. L'intelligence artificielle était aussi
fort présente et attiré l'oeil du CoDir, de la même manière que les nombreuses conférences sur l'inclusion et la
féminisation de nos métiers.
En dehors de cela, nous avons eu l'occasion, de beaucoup travailler sur l'informel
avec Christophe Leurident , Jean-Michel Soors et le directeur de NL, Samuel qui étaient avec nous. Cela nous a donné
l'occasion de prendre le temps de leur expliquer les défis et contraintes auxquels nous sommes confrontés dans nos
projets et notre vie de tous les jours.
Globalement, je retire du salon une vision de l'évolution pour les
prochaines années. Les projets seront intéressants et nombreux, le CoDir est motivé pour les réaliser. Par contre,
une seule déception, SAP n'avait pas de stand au salon. Comme quoi, je vais devoir évoluer.
<<< |
| 03/06/2025 - 13:00 - Tuesday |
true |
Problèmes de mémoire dans SAE |
De : BOENS Patrick
Envoyé : mardi 3 juin 2025 12:59
À : CRECIUN Eduard ; KEINBORG Michael
Cc : BOUCHAT Pierre-Michel
Objet : REACT
Hello à tous
deux,
Avez-vous déjà demandé à Claude 4 Sonnet (ou 3.5 ou 3.7) de vous aider à déterminer ce qui pouvait
effectivement se passer avec REACT ?
Je viens de le faire et …
PROMPT :
Mon équipe construit une application
critique qui utilise REACT. Il semblerait que l'utilisation de REACT nous bouffe de la mémoire petit à petit et après
environ 5h de fonctionnement (même sans rien faire) notre application a consommé toute la mémoire du navigateur (et
du PC) et notre application, pourtant critique, s'arrête de fonctionner.
As-tu déjà entendu parler d'un problème
similaire et quelles sont les pistes de solution ?
RÉPONSE :
Ce type de fuite mémoire (memory leak) dans les
applications React est malheureusement assez courant, surtout pour les applications qui tournent longtemps. Voici les
causes principales et leurs solutions :
Causes les plus fréquentes
Gestionnaires d'événements non nettoyés
• Event
listeners ajoutés sur window, document ou des éléments DOM sans être supprimés
• Solution : utilisez useEffect
avec cleanup dans le return
Timers et intervalles orphelins
• setTimeout, setInterval, requestAnimationFrame non
annulés
• Solution : stockez les IDs et nettoyez-les dans le cleanup
Abonnements non fermés
• WebSockets,
EventSource, observables RxJS laissés ouverts
• Connexions à des APIs temps réel (Socket.io, etc.)
Références
circulaires
• Closures qui capturent des objets volumineux
• Callbacks qui maintiennent des références vers des
composants démontés
State management mal géré
• Redux/Zustand qui accumule des données sans nettoyage
• Caches
qui grandissent indéfiniment
Solutions immédiates
1. Audit avec les DevTools
o Onglet Memory → prendre des
snapshots à intervalles réguliers
o Identifier les objets qui s'accumulent
2. React DevTools Profiler
o Surveiller
les re-renders excessifs
o Identifier les composants qui ne se démontent jamais
3. Pattern de cleanup
systématique
javascript
useEffect(() => {
const handleResize = () => { /* ... */ };
const interval = setInterval(()
=> { /* ... */ }, 1000);
window.addEventListener('resize', handleResize);
return () => {
window.removeEventListener('resize', handleResize);
clearInterval(interval);
};
}, []);
Actions à court
terme
• Ajoutez un redémarrage automatique de l'application toutes les 4h comme palliatif
• Implémentez un
monitoring de la consommation mémoire avec performance.measureUserAgentSpecificMemory()
• Passez en revue tous vos
useEffect pour vérifier les cleanups
Avez-vous déjà identifié des patterns particuliers dans votre code (beaucoup de
timers, connexions WebSocket, state management complexe) ?
-----
Je suis Chef de Projet/Programme. Ce n'est
normalement pas de mon ressort de m'occuper de cela mais je pense que mon input peut aider l'équipe à éliminer le
problème rencontré (absolument rédhibitoire) ce qui s'avérera le cas par la suite : Ahmed a pris le point, a suivi
ce que l'IA nous a renseigné et ... effectivement, le problème a été résolu. LE RÉSULTAT EST UNE APPLICATION SAE
DEVENUE BEAUCOUP PLUS STABLE. |
| 03/06/2025 - 09:00 - Tuesday |
true |
Analyses |
Réponse à Eduard (voir mail encore en dessous)
>>>
Je n’en ai fichtrement aucune idée, Eduard.
Il me semblait
qu’on devait disposer d’un renfort en AF mais … je ne sais pas où en est le suivi de l’annonce ProUnity.
Il
faut absolument reprendre la main sur le processus ET l’officialiser (aujourd’hui … c’est plus que douteux et le
suivi est … lamentable). C’est à travailler : clin d’œil à Pierre.
Bien à vous,
Patrick
<<<
Patrick
Boens Direction transv. - Syst. d'Information
Chef de programme SAM
SAM-PFE / SAM-SAE Boulevard de Merckem 60 • 5000
NAMUR
patrick.boens@letec.be
GSM : +32 495 52 60 20 INFOTEC.BE
De : CRECIUN Eduard
Envoyé : lundi 2 juin 2025 17:00
À : BOUCHAT Pierre-Michel
; BOENS Patrick ; PAELINCK Pierre
Cc
: NAVEZ Vincent ; KEINBORG Michael ; DELFOSSE Dominique
Objet : TR: Communication à SAM-SAE des suppressions de voyage par le flux SIV
Bonjour
messieurs,
Lors de la « pré analyse » comment est-on sensé répondre à ce type de demande ?
Nous n’avons pas
d’analyse technique réalisée pour avancer sur le sujet (pas nécessaire d’avoir Michael dans la boucle). On n’a
personne à ce jour pour faire cette analyse technique. Qui est sensé reprendre le sujet pour répondre à une
estimation haut niveau ?
Bien à vous,
Eduard
De : ARPIGNY Alexandre
Envoyé : lundi
2 juin 2025 16:54
À : CRECIUN Eduard ; KEINBORG Michael ; NAVEZ
Vincent
Cc : DELFOSSE Dominique
Objet : RE: Communication à
SAM-SAE des suppressions de voyage par le flux SIV
Bonjour Messieurs,
J’espère que vous allez bien,
Je me permets
de revenir vers vous concernant le développement potentiel présenté par Dominique.
Auriez-vous une idée de la charge
de travail à réaliser et quand cela pourrait-il être fait ?
Nous avons surtout besoin d’une estimation générale
pour pouvoir trancher si oui ou non ce développement temporaire vaut la peine.
Merci d’avance pour votre
retour,
Cordialement,
Alexandre Arpigny
De : DELFOSSE Dominique
Envoyé : mercredi 30
avril 2025 12:00
À : BIRON David ; BILLON Guillaume ; CRECIUN Eduard
; KEINBORG Michael ; NAVEZ Vincent ;
BECATTINI Jefferson
Cc : BARTIER Maxime ; MORDANT Solange
; BOUCHAT Pierre-Michel ; ARPIGNY Alexandre
; CORDI Vincent ; NSEKA KALEMBA Guy
Objet : RE: Communication à SAM-SAE des suppressions de voyage par le flux SIV
Bonjour à
tous,
Suite à notre réunion de lundi concernant la transmission des suppressions de voyages depuis le flux IV vers
SAM, veuillez trouver, via le lien ci-dessous, le document d’analyse contextuel mis à jour.
FT040 - SupVoyages
BU-SAM (via flux IV).docx
J’ai ajouté, à la fin du document, une liste des user stories qui devraient être
réalisées.
Si vous avez des remarques …
Guillaume, David, Michaël et Eduard pouvez-vous, svp, établir un premier
estimatif de la charge de travail nécessaire, sur base des US ?
Il sera alors possible d’établir un Go / No
go.
Merci à tous
Dominique DELFOSSE DIRECTION GÉNÉRALE
----
À rapprocher avec la nouvelle demande
d'analyste qui devrait paraître sur Prounity (17/09/2025). À prendre en considération dans le budget 2025 et 2026 !
Sujet qui va probablement être traité en Staff Management meeting du 18/09
|
| 02/06/2025 - 19:00 - Monday |
true |
Analyses |
Réponse à Eduard (voir mail encore en dessous)
>>>
Je n’en ai fichtrement aucune idée, Eduard.
Il me semblait
qu’on devait disposer d’un renfort en AF mais … je ne sais pas où en est le suivi de l’annonce ProUnity.
Il
faut absolument reprendre la main sur le processus ET l’officialiser (aujourd’hui … c’est plus que douteux et le
suivi est … lamentable). C’est à travailler : clin d’œil à Pierre.
Bien à vous,
Patrick
<<<
Patrick
Boens Direction transv. - Syst. d'Information
Chef de programme SAM
SAM-PFE / SAM-SAE Boulevard de Merckem 60 • 5000
NAMUR
patrick.boens@letec.be
GSM : +32 495 52 60 20 INFOTEC.BE
De : CRECIUN Eduard
Envoyé : lundi 2 juin 2025 17:00
À : BOUCHAT Pierre-Michel
; BOENS Patrick ; PAELINCK Pierre
Cc
: NAVEZ Vincent ; KEINBORG Michael ; DELFOSSE Dominique
Objet : TR: Communication à SAM-SAE des suppressions de voyage par le flux SIV
Bonjour
messieurs,
Lors de la « pré analyse » comment est-on sensé répondre à ce type de demande ?
Nous n’avons pas
d’analyse technique réalisée pour avancer sur le sujet (pas nécessaire d’avoir Michael dans la boucle). On n’a
personne à ce jour pour faire cette analyse technique. Qui est sensé reprendre le sujet pour répondre à une
estimation haut niveau ?
Bien à vous,
Eduard
De : ARPIGNY Alexandre
Envoyé : lundi
2 juin 2025 16:54
À : CRECIUN Eduard ; KEINBORG Michael ; NAVEZ
Vincent
Cc : DELFOSSE Dominique
Objet : RE: Communication à
SAM-SAE des suppressions de voyage par le flux SIV
Bonjour Messieurs,
J’espère que vous allez bien,
Je me permets
de revenir vers vous concernant le développement potentiel présenté par Dominique.
Auriez-vous une idée de la charge
de travail à réaliser et quand cela pourrait-il être fait ?
Nous avons surtout besoin d’une estimation générale
pour pouvoir trancher si oui ou non ce développement temporaire vaut la peine.
Merci d’avance pour votre
retour,
Cordialement,
Alexandre Arpigny
De : DELFOSSE Dominique
Envoyé : mercredi 30
avril 2025 12:00
À : BIRON David ; BILLON Guillaume ; CRECIUN Eduard
; KEINBORG Michael ; NAVEZ Vincent ;
BECATTINI Jefferson
Cc : BARTIER Maxime ; MORDANT Solange
; BOUCHAT Pierre-Michel ; ARPIGNY Alexandre
; CORDI Vincent ; NSEKA KALEMBA Guy
Objet : RE: Communication à SAM-SAE des suppressions de voyage par le flux SIV
Bonjour à
tous,
Suite à notre réunion de lundi concernant la transmission des suppressions de voyages depuis le flux IV vers
SAM, veuillez trouver, via le lien ci-dessous, le document d’analyse contextuel mis à jour.
FT040 - SupVoyages
BU-SAM (via flux IV).docx
J’ai ajouté, à la fin du document, une liste des user stories qui devraient être
réalisées.
Si vous avez des remarques …
Guillaume, David, Michaël et Eduard pouvez-vous, svp, établir un premier
estimatif de la charge de travail nécessaire, sur base des US ?
Il sera alors possible d’établir un Go / No
go.
Merci à tous
Dominique DELFOSSE DIRECTION GÉNÉRALE
----
À rapprocher avec la nouvelle demande
d'analyste qui devrait paraître sur Prounity (17/09/2025). À prendre en considération dans le budget 2025 et 2026
|
| 02/06/2025 - 13:00 - Monday |
false |
|
Demande de Daniel Paisse concernant le point PFE à la CFT : peut-il être maintenu pour le 23 juin prochain.
Mail de
ma part à Nicolas Forget, Christian Pochet, Vincent Cordi et Alexis Lefebvre.
>>>
Au départ, c’était ViCo qui
devait présenter une situation.
Daniel doit finaliser l’ordre du jour de la réunion du 23 ce mardi.
Qu’est-ce
qui est prévu ?
Bien à vous,
Patrick
|
| 02/06/2025 - 12:00 - Monday |
true |
Article SAM Central |
De : NAVEZ Vincent
Envoyé : lundi 2 juin 2025 13:06
À : BOENS Patrick
; BECATTINI Jefferson ; CRECIUN Eduard ;
NSEKA KALEMBA Guy ; DUVIVIER Nicolas
Cc : HACHEZ David
Objet : RE: J'ai commis un autre article pour SAM Central
Salut Patrick,
Je trouve ça
chouette, motivant.
Bien sûr je suis ok avec l’objectif et le soutenir. Comme depuis de nombreuses années (sûrement
depuis que je suis ‘TECien’).
Le hic, ça va être de convaincre des gens qui n’y croient plus depuis 20 ou 20 ans
de service. Et ils en ont vu des promesses non réalisées j’imagine.
Je me mets à la place de ‘vieux’
collègues... 😅
La phase qualité qui se termine le 31/7 ? Après, plus besoin de faire de la qualité alors ?
Si,
si … effectivement … faudrait peut-être rephraser. L’idée était de dire « après le 31/07, nous ne devrions
plus avoir d’interruption de service » (juste des petites exceptions qui ne vont pas entacher le fonctionnement de
SAE).
S’engager et promettre, c’est super. Mais il faut pouvoir l’assumer.
Oui, c’est aussi pour cela que
j’ai inclus Eduard car c’est, effectivement, ambitieux. Pas de problème pour moi pour dire 30/09 au lieu de 31/07,
par exemple.
Si l’objectif n’est pas atteint, même si c’est pour une raison extérieure comme management,
budget, etc, personne n’ira chercher la véritable info et ce sera sûrement le mantra « comme d’habitude au TEC
».
Souvent, on parle de choses grandioses en réunion ou présentation, mais on réalise des choses plus petites
parfois avec grandes difficultés.
Hmm … là c’est une question de qualité de code et nous ne devrions pas avoir
de raison exogène. Cela demande un commitment évidemment.
De : BECATTINI Jefferson
Envoyé : lundi 2 juin 2025 11:18
À : BOENS Patrick
Objet : Re:
J'ai commis un autre article pour SAM Central
Hello Patrick,
Au niveau de ma réaction "à chaud" :
C'est très
ambitieux dans le statement, néanmoins pour moi c'est ce vers quoi nous devons impérativement nous diriger
actuellement. Donc je suis totalement d'accord avec l'objectif et forcément je le soutiens. Ma seule petite crainte,
c'est que nous faisons une promesse trés trés ambitieuse (Car très attendue par nos utilisateurs) et si nous
n'arrivons pas à la tenir le retour de bâton pourrait être violent.
Mais sinon : Je suis plus que totalement ok,
c'est exactement ce que nous devons réaliser aujourd'hui.
Réponse de Patrick:
… c’est bien pour cela que je
demande votre avis ! Je sais par expérience que le zéro-defect n’existe pas : l’important est pour autant de
pouvoir minimiser les erreurs pour que nous ne soyons jamais en « interruption de service », et cela, c’est
atteignable. Peut-être pas pour le 31/07. À discuter dès lors ! 😉
Bàt,
Patrick
-------------
Au final, même
si l'article est ambitieux, Jefferson et Vincent sont d'accord ce qui a d'ailleurs été le cas du reste de l'équipe.
Mais ... y'a du boulot
|
| 02/06/2025 - 11:02 - Monday |
false |
Qualité Totale : article sur SAM Central |
>>>
SAE: Qualité Totale
BOENS Patrick
Chef de projets SAE
3 min de lecture
Qualité Totale : l'excellence sans
compromis
Des cendres de Phénix naît l'aspiration à l'excellence
Les fondations ont été consolidées, les flux
audités, les fragilités identifiées. La phase Phénix a tenu ses promesses : elle a révélé un système parfois
fragile et nous a permis de bâtir une base plus robuste, plus intelligente, plus lisible. Mais l'oiseau mythique n'a
pas fini sa métamorphose. Car si renaître de ses cendres était le premier défi, tendre vers la perfection est le
suivant.
Aujourd'hui s'ouvre la phase Qualité Totale, deuxième acte de notre quête de stabilisation. Là où
Phénix était renaissance, Qualité Totale aspire à la maîtrise absolue. Là où nous réparions, nous souhaiterions
prévenir désormais. Là où nous corrigions, nous aimerions anticiper. L'objectif devient d'être TOTALEMENT
irréprochable. Sacrée ambition.
Le terme peut paraître audacieux, voire utopique. Pourtant, il exprime une vérité
simple : dans un système critique comme le SAE, il n'y a pas de place pour l'à-peu-près. Chaque erreur, aussi minime
soit-elle, est une faille dans la confiance que nos utilisateurs placent en nous. Chaque dysfonctionnement, même
fugace, est un grain de sable dans l'engrenage de l'exploitation. La Qualité Totale, c'est l'ambition de chasser ces
imperfections jusqu'à la dernière. Repousser les limites.
L'art de la vigilance permanente
Pour tendre vers cet
idéal du zéro défaut, nous avons instauré un monitoring permanent, un œil qui ne dort jamais. Chaque battement du
système est scruté, chaque respiration analysée. Les connexions réseau sont surveillées en temps réel, leurs
performances mesurées à la milliseconde près. Le moindre ralentissement devrait déclencher une alerte, la plus
petite anomalie mobiliser l'équipe.
Cette vigilance se veut réactive, chirurgicale, implacable. Dès qu'une erreur
se présente, elle devrait être capturée, disséquée, comprise. Son origine traquée, sa cause éradiquée, sa
récurrence rendue impossible. Car il ne suffit pas de corriger : il faut comprendre pour ne plus subir.
Cette
délicate tâche est dévolue à notre équipe de testing qui s'est renforcée avec l'arrivée de Nicolas Duvivier.
Courage, Nicolas !
La métrique de l'excellence
Le calendrier nous donne un premier cap : le 31 juillet prochain. Cette
date n'est pas arbitraire, elle est l'horizon de notre ambition. C'est le moment où nous prévoyons de livrer la
nouvelle étape de la partie « Transporteurs » : cartographie historique et cartographie temps réel. D'ici là, notre
objectif est que chaque ligne de code soit passée au crible, chaque flux de données optimisé, chaque point de
défaillance potentiel éliminé. Le zéro défaut n'est plus une simple aspiration, c'est un engagement vers lequel
nous tendons. Mais quel objectif ! Gageons que cela nous demandera de passer et repasser sur le même code de nombreuses
fois, dans une série de circonstances différentes, pour effectivement capturer toutes les conditions dans lesquelles
le contexte nous pousse dans les cordes : nous voulons qu'elles nous permettent maintenant de rebondir les poings en
avant pour de nouveaux démêlés. Nous sommes prêts.
Cette exigence transforme progressivement notre façon de
travailler. Chaque développement devrait être pensé sous l'angle de la robustesse, chaque déploiement testé
jusqu'à l'obsession. Les métriques ne mentent pas : elles deviennent notre boussole, nos performances, notre
fierté.
L'héritage de Phénix, l'ambition de l'excellence
La phase Phénix nous a appris à renaître. La Qualité
Totale nous invite à exceller. Si la première était un chantier de reconstruction, la seconde aspire à être un art
de l'affinement. Nous ne construisons plus seulement un système qui fonctionne : nous cherchons à façonner un outil
qui inspire confiance, qui rassure par sa constance, qui impressionne par sa fiabilité. Qui séduit par sa simplicité
et son utilité.
Car le SAE n'est pas qu'une application critique : c'est le cœur battant de l'exploitation du TEC.
Et ce cœur, nous voulons qu'il batte avec la régularité d'un métronome, la précision d'une horloge suisse, la
constance d'un phare dans la tempête.
La Qualité Totale commence aujourd'hui. Elle vise le 31 juillet. Entre ces deux
dates, une seule règle guide nos efforts : tendre vers l'excellence, sans compromis.
Pas de mots, des actes …
Voici
quelques exemples de ce que nous capturons, examinons, corrigeons…
<<< |
| 02/06/2025 - 10:15 - Monday |
true |
Setup SAE |
En conclusion d'un meeting de revue de setup de l'équipe PFE :
Donc … en un mot comme en cent, ou en un mot
commençant … NOUS AVONS UNE GIGANTESQUE ERREUR DE CASTING : L’ÉQUIPE SAE N’A PAS LA CARRURE POUR CONSTRUIRE ET
MAINTENIR UNE APPLICATION CRITIQUE COMME SAE ! LE MÊME CONSTAT EST FAIT SUR DES ÉQUIPES/RESSOURCES SATELLITES COMME
ARCHITECTURE et INFRASTRUCTURE (cfr. SAM-Light)
De plus, la topologie de l’équipe NE COUVRE PAS les recommandations
d’une Software Factory moderne.
Un travail de fond doit être mené sur ces sujets pour être à la mesure d'assurer
l'évolution d'une application critique comme SAE.
|
| 30/05/2025 - 14:06 - Friday |
true |
CoPil du 06/06 |
Mail à l'équipe PFE pour le CoPil car celui-ci sera essentiellement consacré à la PFE :
>>>
Hello à tous,
Le
CoPil du 06/06 est essentiellement consacré à PFE.
En voici le slide d’ouverture (slide normal d'ouverture avec le
RAG, les points d'attention, le "réalisé", le "en cours", le "à venir".
Êtes-vous d’accord avec le message
général et le statut ? Ma position est de se dire que nous nous sommes améliorés sur tous les sujets et qu’au
global nous avons quitté la zone rouge (mais attention : pas de relâchement ! 😉) car ce n’est pas encore gagné
!
Je n’ai pas encore de « Risk Heatmap » (cela viendra dans le CoPil suivant) mais … nous devons absolument
adresser la partie liée au trou entre fin 2026 et le début de l’assemblage/ montage qui suivra la disponibilité du
marché que nous préparons (Gérald) ! 😉
Bien à vous,
Patrick
PS : ne tenez encore aucun compte de la partie
droite de ce slide : « Réalisé », « En cours » et « Prochaines étapes »
<<< |
| 28/05/2025 - 17:00 - Wednesday |
true |
PFE : Crise Bloc Comm |
Dans le Project PSI de l'entreprise, une nouvelle crise est annoncée : la crise Bloc Comm.
Planification :
ROUGE
Budget : VERT
- Problèmes de connectivité de la 2G (crise blocs COM)
- Migration SAE Liège
- Retard planning
sur intégration Hastus et Transporteurs
- Trajets à redéfinir pour suppression de voyage, Hastus, Décarbonation
-
Qualité sur l'outil SAE - dette technique importante
- Souci de gouvernance dans l'équipe IT-DSE (processus de
développement et acceptation)
Il est à noter que cette crise n'a jamais été officiellement annoncée par le
Management. Elle fait suite à la prise de conscience que l'arrêt de la 2G prévue en décembre 2029 sera d'une
manière ou d'une autre effective bien avant, en juin 2026 annonce Proximus car, dans l'intervalle, les entretiens et/ou
réparation des antennes 2G ne se fera que sous forme de "best effort". Cette information a été remontée par le point
que j'ai fait suite à la visite de Proximus (PXS) dans nos locaux et aux contacts téléphoniques que j'ai pris avec
Marc Capelle (PXS). |
| 28/05/2025 - 09:26 - Wednesday |
true |
Département IT global : réorganisation IT acceptée par le Comité de Direction |
Message de Christian Pochet sur "Coin Café" (Teams):
>>>
Bonne nouvelle : la nouvelle organisation de la direction IT
a été validée par le Comité de direction !
Le Codir a salué cette structuration en trois pôles IT (Opérationnel,
Solutions métier, et Appui transversal) comme une évolution logique, cohérente avec l’organisation de
l’entreprise, et porteuse de plus de clarté, d’efficacité et de pilotage.
À terme, les pôles seront renommés
« départements », les anciens départements deviendront des services (point encore à finaliser avec RH), et
l’architecte d’entreprise deviendra architecte IT, avec un rôle recentré sur la direction IT.
Cette évolution
vise à répondre à plusieurs enjeux concrets :
Créer une logique de Business Unit (Pôle) ayant une autonomie de
direction
Clarifier la chaîne de décision et les responsabilités, pour éviter les flous organisationnels.
Mieux
reconnaître et structurer les expertises présentes dans l’équipe IT.
Regrouper à moyen terme les compétences IT,
pour limiter les silos et renforcer la cohérence de nos actions.
Les nouveaux responsables de pôles seront
progressivement appelés à jouer un rôle de direction à part entière, aux côtés du directeur IT. Cette nouvelle
gouvernance en quatre têtes (au lieu de deux) vise à rapprocher la prise de décision du terrain et à mieux répartir
les responsabilités.
La transition se fera progressivement, en s’appuyant sur les responsables d’équipes, vos
retours et votre engagement, pour construire ensemble une organisation plus lisible et plus efficiente.
Une version
mise à jour de la présentation est jointe à ce message.
Un « pulse check » sera lancé prochainement pour
recueillir vos ressentis et ajuster, si nécessaire, le déploiement de cette nouvelle organisation.
Merci à toutes
et tous pour votre implication.
<<<
L'annonce est flanquée d'une nouvelle présentation Powerpoint |
| 21/05/2025 - 09:28 - Wednesday |
true |
PFE : Crise Bloc Comm - Conversation avec Benoit Castres |
21/05/2025 - 09:28
Hello Benoit,
Dis ... j'aurais besoin d'une feuille Excel avec le matériel à commander,
élément par élément, avec pour chaque ligne :
1) Le nom
2) La quantité à commander
3) La date de commande (s'il
y en a une)
4) La date estimée de réception
5) Le montant TVAC de la commande (à propos, sais-tu si le TEC récupère
la TVA? Si oui, alors j'ai besoin du montant HTVA)
6) Fournisseur / marché
Peux-tu me fournir cela, Benoit ?
Bien
à toi,
Patrick
21/05/2025 - 09:35
Bonjour Patrick, je vais voir avec Dimitri il devait me renvoyer la
liste de pièces avec les dernières modifications apportées à la PFE.
PaBo : 21/05/2025 -
10:41
Christian me demande un statut PFE pour ce soir et je voudrais pouvoir le lui fournir.
PaBo :
21/05/2025 - 11:31
Benoit, il faut que tu prennes directement en charge la commande de 400 MC100. Je ne sais
pas si Alexis t'en a informé. Quand tu fais la commande, il faut mettre ViCo et ChPo en copie. Je te conseille
également de mettre NiFo en copie.
PaBo : 21/05/2025 - 12:09
Désolé ... je te suscite ! Il nous reste
la présente semaine et la semaine prochaine avant l'arrivée d'Alexandre (02/06). Il faut voir avec Xavier et Dimitri
ce qu'il y a de précis et concret à faire avant son arrivée (atelier, recette de cuisine, ...)
BeCa :
21/05/2025 - 12:14
Oui justement j'ai fait le point avec Xavier je regarde les cartons et emballages pour les
éléments assemblés prêts à être expédié pour pouvoir les commander
Et pour la commande de MC-100 je regarde ca
aussi, je reboucle avec Xavier et Dimitri il me semblait qu'ils faisaient encore quelques tests sur l'écho
PaBo :
21/05/2025 - 13:56
Ils font des tests, oui, mais la décision a été prise de procéder à la commande lors
du meeting de vendredi. Au pire, on peut encore arrêter la commande endéans les 3 semaines si jamais on trouvait un
truc rédhibitoire.
Donc ... GO pour la commande via le M018 des MC100.
J'ai aussi besoin de savoir où on en est
avec la commande des Teltonika.
Et pour les deux sujets .... j'ai besoin de savoir quand on recevra le matériel.
Au
surplus, il y a plein d'autres choses à commander (ou qui sont déjà commandées) : câbles, blocs HMI, PCSBs, ...
Faudrait qu'on ait une vue là-dessus (moi, ce qui m'intéresse, ce sont essentiellement les dates auxquelles on peut
attendre les livraisons ... car cela me permet de bétonner notre planning de construction des PFE V2).
PaBo :
21/05/2025 - 16:09
Donc ... je compte sur toi pour que la commande des boîtes de carton soit faite
aujourd'hui, hein !
BeCa : 21/05/2025 - 16:10
Laurence n'est plus là mais demain matin je lui envoie
tout ce qui est nécessaire pour le faire à la première heure
PaBo : 22/05/2025 - 13:24
C'est fait
?
PaBo : 22/05/2025 - 13:26
J'ai eu Marc au téléphone il nous envoie le bon de commande dès que
possible, pour le moment il manque encore un document commercial entre Proximus et MC Technologies à valider/signer
avant de pouvoir passer commande
PaBo : 22/05/2025 - 13:32
Parfait
Suis ce truc, hein !
PaBo : mardi
27/05/2025 - 14:18
Benoit, j'ai absolument besoin de
(1) La liste de matériel qui constitue la PFE V2 (tout
tout tout compris, câbles, HMI, PCB, ...)
(2) La liste du matériel en commande selon grille qui t'a été donnée
... j'ai besoin de ces infos pour le CoPil du 06/06 et ChPo vérifie les slides que je dois finaliser pour le 03/06
BeCa : 27/05/2025 - 15:59
Je fais revoir la liste que j'ai par Dimitri/Xavier, d'ici le 3/6 j'aurai mis à jour
les stocks/Commandes
PaBo : 27/05/2025 - 16:06
Je dois avoir quelque chose pour vendredi, Benoit, au moins pour
l'état des commandes
PaBo : 28/05/2025 - 09:04
Benoit, où en est la commande des MC100 ?
Et où en est la
commande des Teltonika ?
BeCa : 28/05/2025 - 09:35
Bonjour Patrick, les MC100 on en parle avec Proximus à
11h, pour les Telto j'ai pas eu de retour de Laurence donc encore dans le pipe pour signature
PaBo : 28/05/2025 -
09:42
J'ai besoin de davantage de proactivité, Benoit.
Il faut que je sente que tu prennes vraiment les trucs
en main
PaBo : 28/05/2025 - 17:21
Peux-tu mettre les documents de travail dans le répertoire du projet,
Benoit ? P027 - Projet PFE V2 | PROJETS @ Systèmes Embarqués | Microsoft Teams
Merci d'avance
BeCa :
04/06/2025 - 16:02
Si tu es disponible avant 16h30 tu peux m'appeler, j'ai mis le point à cette heure là
comme tu n'étais pas disponible avant
PaBo : 04/06/2025 - 16:06
Je suis dispo dès maintenant mais
invite aussi Alexis, stp
|
| 15/05/2025 - 09:43 - Thursday |
true |
Département IT global : annonce d'une réorganisation |
Message de Christian Pochet (CIO) sur "Coin Café" :
>>>
Bonjour à toutes et à tous,
Depuis plusieurs mois, j’ai
mené un travail de réflexion sur notre organisation au sein de la direction IT. Ce travail a abouti à une proposition
de réorganisation, validée récemment par notre administrateur général. Elle sera encore présentée au Codir la
semaine prochaine, puis au staff DT et aux BU début juin, avant une mise en œuvre officielle.
Cette nouvelle
organisation s’inspire de la structure de l’entreprise, qui repose elle-même sur trois pôles coordonnés par un
comité de direction restreint. Elle vise à rendre notre fonctionnement plus clair, plus réactif et plus concerté,
notamment dans la manière dont nous prenons nos décisions.
Elle s’organisera autour de trois pôles IT :
un pôle
Opérationnel,
un pôle Solutions métier,
un pôle Appui transversal.
J’ai nommé dès aujourd’hui les trois
responsables de ces pôles :
Benoit Tielmance pour le pôle Opérationnel
Nicolas Forget pour le pôle Solutions
métier
Manu Lekeu pour le pôle Appui transversal
Ils auront pour mission de prendre progressivement le relais, de
dialoguer avec les équipes, et de contribuer à poser les bases de cette nouvelle organisation.
Même si elle ne sera
officialisée qu’après les présentations aux différentes instances de gouvernance, j’ai souhaité lancer dès
maintenant une phase de transition, afin de donner de la clarté et de la cohérence à notre fonctionnement dès
aujourd’hui.
Je suis conscient que cela pourra susciter des questions, voire des inquiétudes. Ce changement ne
remet pas en cause ce qui fonctionne : il vise à clarifier les rôles, à mieux structurer les projets, et à soutenir
chacun d’entre vous dans votre mission.
Vous trouverez en pièce jointe une présentation synthétique qui vous
permettra de découvrir les grandes lignes de la nouvelle organisation.
Merci à toutes et à tous pour votre
engagement.
Bien à vous,
Christian
<<<
L'annonce est ponctuée d'une présentation Powerpoint qui sera d'ailleurs
utilisée pour orienter les équipes SAE et PFE |
| 07/05/2025 - 16:34 - Wednesday |
true |
Département IT global |
Message de Christian Pochet sur "Coin Café" (Teams):
>>>
Bonjour à toutes et tous,
Les résultats de l’enquête
de satisfaction IT ont désormais été partagés avec le Comex et publiés sur notre intranet Inside. Vous trouverez en
pièce jointe le rapport complet qui reprend l’analyse détaillée de ces retours.
Je souhaitais vous adresser
directement un mot car ces résultats sont avant tout le reflet de votre travail collectif. La qualité perçue
aujourd’hui est le fruit des efforts menés depuis plusieurs années pour améliorer nos services, renforcer notre
proximité avec les métiers et bâtir une IT solide et fiable. Le niveau global de satisfaction traduit cette
reconnaissance, en particulier sur le support et l’accompagnement que vous apportez au quotidien.
L’enquête met
aussi en lumière des sujets sur lesquels nous devons poursuivre nos efforts. Nous avons déjà engagé des actions
concrètes sur ces points, et les échanges réguliers avec les directions nous permettront de continuer à ajuster
notre réponse.
Cette enquête confirme que nous sommes sur la bonne voie. L’amélioration continue reste au cœur
de notre démarche. C’est grâce à votre engagement quotidien, à votre professionnalisme et à votre capacité à
accompagner les métiers que nous avons pu atteindre ce niveau de reconnaissance.
<<< |
| 11/04/2025 - 00:00 - Friday |
false |
|
On en est au deuxième meeting d’affilée où il faut insister pour que soit une bonne fois pour toutes actée la
décision de faire du MC100 la solution préférée et d’acter aussi que le Peitel reste la solution de secours. |
| 11/04/2025 - 00:00 - Friday |
false |
|
Annonce officielle de la réorganisation suivie d’un drink. DSE restera désormais DSE et non DSTO. Alexis, Pierre et
Eduard sont officiellement intronisés en qualité de Chefs de Service.
|
| 10/04/2025 - 00:00 - Thursday |
false |
|
|
| 09/04/2025 - 00:00 - Wednesday |
false |
|
|
| 08/04/2025 - 00:00 - Tuesday |
false |
|
Xavier envoie un mail à toute l’équipe PFE et Vincent Cordi pour indiquer son extrême agacement de la situation.
Pour lui, rien n’avance et c’est essentiellement dû à Alexis et Vincent (opinion de Xavier). Réunion de crise
dans le labo. Prise de parole de Vincent et de Christian |
| 07/04/2025 - 00:00 - Monday |
false |
|
|
| 04/04/2025 - 00:00 - Friday |
false |
|
Suivi de crise PFE ahurissant : personne ne lit les minutes qui sont réalisées et on remet Peitel en tête de la
course : personne ne se tient aux décisions et actions éntérieures. |
| 03/04/2025 - 00:00 - Thursday |
false |
|
Suite à de nouveaux débordements, la situation est éclaircie avec Alexis. Meeting de planning avec XaMo et DiDu |
| 02/04/2025 - 00:00 - Wednesday |
false |
|
Attaque de ViCo sur mon rôle dans la situation actuelle. Mise au point et clarification. Les choses se mettent en place
mais TRÈS lentement. Je sens une opposition de AlLe malgré la mise au point. |
| 02/04/2025 - 00:00 - Wednesday |
false |
|
Clarification de ce qui est attendu dans la zone grise. Participation à meeting avec EdCr + PiBo. Ai donné mon input :
ai dit que ces choses étaient à voirnentre reux mais que je comprenais que cela pouvait impacter le planning de la
carto historique et carto temps réel. |
| 01/04/2025 - 00:00 - Tuesday |
false |
|
Obtention d’un plan d’occupation du monteur Alexandre qui a été soumis à Christian Pochet. Christian accepte de
procéder à l’engagement du monteur Alexandre. |
| 01/04/2025 - 00:00 - Tuesday |
false |
|
Gros souci d’import de données menant à un incident P1 dans SAE. Situation critique le même jour qu’une mep avait
été planifiée pour 10h30. |
| 31/03/2025 - 00:00 - Monday |
false |
|
Refus de AlLe de participer à la revue du Cycle Planning |
| 28/03/2025 - 00:00 - Friday |
false |
|
Revue planning en vue du Cycle Planning du 01/04 |
| 27/03/2025 - 00:00 - Thursday |
false |
|
Demande de |
| 26/03/2025 - 00:00 - Wednesday |
false |
|
Demande de |
| 25/03/2025 - 00:00 - Tuesday |
false |
|
Demande de nettoyer la colonne « Resolved » pour le 28/03 et la colonne « Active » du backlog pour le 04/04. Demande
de fonctionner en mode Scrumban avec capacité réservée de 20% pour les AMI |
| 24/03/2025 - 00:00 - Monday |
false |
|
Rappel à AlLe de la nécessité d’avoir un planning (.mpp – ligne de temps) |
| 24/03/2025 - 00:00 - Monday |
false |
|
|
| 05/03/2025 - 09:00 - Wednesday |
true |
Alerte sur le testing |
Le 05/03 une alerte de testing est lancée pour le Chef de Département, Vincent Cordi. En effet, en consultant le
backlog de l'équipe SAE le PM se rend compte que la liste des choses sur lesquelles l'équipe travaille est de 92
éléments. POur une équipe de 10 personnes environ, cela fait grosso modo 9 sujets "simultanés". Ce n'est pas
gérable ! Rappel de SSSF - Stop Starting; Start Finishing. Le PM en déduit qu'il doit y avoir un manque de focus sur
ce qui est à faire. Mais plis inquiétant encore : la liste des choses qui sont à tester atteint 246 éléments alors
qu'elle est dévolue à une et une seule personne. Le PM réagit donc et invite le Chef du Département DSE à
réfléchir à engager plusieurs nouveaux testeurs pour absorber la tâche. Un mois plus tard, environ au début du mois
d'avril, le nombre d'éléments à tester en est à 239. Ainsi, en un mois de temps, le seul et unique testeur a réussi
à traiter 7 élements net (c'est-à-dire la différence entre ce qu'il y avait dans la liste + les nouvelles choses qui
y sont entrées, et les éléments qui en sont sortis). Il reste donc 239 éléments avec une vélocité de 7/mois, donc
34 mois de travail ! Impensable ! Une nouvelle alarme est envoyée au Chef de Département.
Le 05/03 ... nous sommes
exactement au moment de la première tentative de bascule LV. Des problèmes sont remontés par CDS (Bastien Ypersiel)
et ne sont pas traités par les développeurs.
La cause semble évidente au PM qui observe que les tâches qui sont
prises par les membres de l'équipe ne sont pas prises dans un ordre de priorité approprié. De fait, même les tickets
enregistrés dans Azure DevOps sont désordonnés car personne ne leur assigne de priorité (on se contente de créer
des tickets et leur priorité est systématiquement mise à 2, le défaut d'Azure DevOps). SI tous les tickets ont la
même priorité, il n'y a pas de priorité en fait. Le PM le signale et insiste pour que désormais les tickets
reçoivent une priorité établie manuellement et qui corresponde effectivement à l'urgence exprimée, notamment par
Bastien Ypersiel.
Par ailleurs, vu la quantité de tickets dans le backlog (rarement nettoyé) implique un travail de
plusieurs jours, temps dont ne dispose pas l'équipe en cette période de bascule LV.
Enfin, le PM se rend compte que
c'est le Dev Lead, aussi Scrum Master, qui effectue tant bien que mal le nettoyage et non le Product Owner comme ce
devrait être le cas. Il apparaît alors nécessaire au PM, Patrick Boens, de travailler sur la méthode et la rigueur
avec l'équipe SAE.
Revenant sur les aspects testing, les mesures ne sont finalement prises par le Chef de Département
qu'à la fin du mois d'avril. Ce délai montre que la vitesse de réaction au TEC est très largement en-dessous des
normes du marché, surtout eu égard à la criticité de l'application ! C'est vraiment un "red flag" !
|
| 14/02/2025 - 00:00 - Friday |
false |
|
Premier meeting de crise par ChPo. |
| 13/02/2025 - 00:00 - Thursday |
false |
|
Meeting RingRing (alternative à) ; Meeting des prios SAE avec PiBo. SAE : meeting avec MiKe. Pas de recouvrement entre
ce que je vois chez MiKe et attentes de PiBo (concentration des plannings). |
| 12/02/2025 - 00:00 - Wednesday |
false |
|
|
| 11/02/2025 - 00:00 - Tuesday |
false |
|
Premier CoPil auquel j’assiste. Catastrophique. Pas de structure, pas de message clair, pas de demande de points de
décisions. Je n’ai jamais vu un aussi mauvais CoPil et … dirigé par le chef de département : ViCo. CoPil tard en
fin de journée (17h à 18h30) |
| 10/02/2025 - 00:00 - Monday |
false |
|
Liaison Main Courante Tram vers systèmes du TEC :mail à EdCr et PaBo (phase finale de la réalisation du projet tram).
Mais qu’est-ce que c’est que cette histoire ? Où suis-je tombé pour recevoir le samedi matin un appel en urgence
du manager du département sur des sujets de crise (donc origine bien antérieure à mon arrivée). Demande de MS
Project (c’est le minimum pour un PM) |
| 08/02/2025 - 00:00 - Saturday |
false |
|
SAMEDI : appel de ViCo : on rentre en crise ! Et ViCo me donne le pilotage de la crise (mail du samedi 08/02).
Instructions pour AlLe et DiDu : besoin d’un planning de production PFE V2 pour le 10/02 ; pour AlLe : nouveau bloc
comm, ODB et HMI selon instructions de ChPo. Reste de l’équipe : se concentrer sur le Peitel, V1 et V2 (JeCh : partie
SW ; DiDu : partie HW). Si pas de résultat pour le 19/02 du point de vue Peitel, ViCo considérera que dette technique
insurmontable. Pour SAE, je ne comprends rien à ce qui est indiqué dans le mail de ViCo (Chinois pour moi car pas de
Knowledge Transfer le 06/02 et le 07/02, absence de ViCo) |
| 07/02/2025 - 00:00 - Friday |
false |
|
IDEM. ViCo pas au bureau pour problèmes de dos. Tram de Liège pas dans le périmètre infra selon olivier Detiege.
Report de « faire connaissance avec AlLe » car CoPil bcp de boulot (remise au 12/02) |
| 06/02/2025 - 14:16 - Thursday |
false |
|
Mail de John D'Ursel concernant le tram de Liège
Hello à tous,
Actuellement, les rames sont toujours configurées en
QAS et ne sont pas encore créées dans SAP.
Je n’ai actuellement aucune idée des ODM qui seront utilisés, je pose
la question et espère avoir une réponse positive.
Les logs et métriques remontent actuellement via le canal Grafana.
Similaire à la V2.
Les infos Ordibus/Géoloc sont disponibles sur base des trames de navigation transmises par le SAE
du tram. S’il n’y a pas d’ODM, aucune information vraiment intéressante ne sera remontée. Sur la plupart des
rames, le SAE a été désactivé en attente d’une correction côté Inéo. Si cette correction est réalisée à
temps on devrait avoir des données.
Bien à vous,
John.
Mail plus tard vers 17h:
Aux dernières nouvelles :
- Le
SAE du Tram enverra-t-il des données à la PFE?
-> Cela sera fonction de la disponibilité de la correction par les
équipes Inéo et la remise en route des communications entre le SAE Inéo et la PFE
- Est-ce que les valideurs seront
activés avec ODM/service/voyage ?
-> Probablement, si le SAE Inéo transmet des infos à la PFE
- Quels seront les
ODM utilisés ?
-> Olivier Stassard ou Olivia Perwez en charge de cette partie pourront peut-être nous répondre
- Les
valideurs devront-ils utiliser des abonnements de PRD ? Les rames doivent passer en PRD ?
-> On reste en QAS, a moins
qu’il ne faille passer en PRD pour effectuer un parcours client complet (ex : s’il y a des limitations majeures à
rester en QAS).
-> Toutes les rames vont sortir. Si les parcours client peuvent être réalisés en QAS, on reste en
QAS.
-> On basculera alors en PRD en fin de marche à blanc.
-> Les AVMs Conduent sont aussi actuellement en
QAS.
- Quelle est la durée de la marche à blanc?
-> La marche à blanc à une durée de deux mois. Elle commence le
11/02 et se termine le 14/04.
-> On est en exploitation dès le 15/04
|
| 06/02/2025 - 00:00 - Thursday |
false |
|
J’ai des documents à lire (CoPIl, fiches projet et document de réorg) mais pas vraiment de knowledge transfer.
Meeting sur RingRing. Priorité de gestion de la marche à blanc du tram de Liège (prio selon ViCo). |
