Posture professionnelle

Organisation & méthodologie

Gérer deux modes simultanés : le temps long du projet et le temps court du support, sans laisser l'un saborder l'autre.

Ma définition

L'organisation, dans un contexte d'ingénierie en alternance, c'est savoir gérer deux modes simultanés : le temps long du projet (planification par phases, jalons, dépendances entre tâches) et le temps court du support (interruptions, urgences, tickets entrants). La difficulté n'est pas de faire l'un ou l'autre : c'est de ne pas laisser l'un saborder l'autre.

Dans un environnement comme Criteo, où je contribue à des projets plurimensuels tout en assurant du support N1/N2/N3 pour 2 000+ collaborateurs, la gestion des priorités est une compétence quotidienne. Une bonne organisation, c'est aussi ce qui rend possible le travail en autonomie : sans structure, l'autonomie devient du désordre.

Points clés

Double mode

Temps long du projet (sprints, jalons, dépendances) et temps court du support (urgences, tickets, interruptions), les deux en simultané.

Priorisation rigoureuse

Sans structure, l'autonomie devient du désordre. L'organisation est ce qui rend possible le travail en autonomie sur des projets complexes.

Jira comme outil de pilotage

Suivi des sprints, phasing, visibilité en temps réel sur ce qui est en cours, bloqué, ou à risque.

Mes éléments de preuve

Extension réseau → : gestion Agile par phases

Le déploiement de l'Innovation Hub a été géré en mode Agile avec des sprints hebdomadaires suivis dans Jira, et les plans de câblage mis à jour en continu. Quatre phases principales ont structuré le déploiement : phase préparatoire (site survey, schémas d'architecture, sélection du matériel), phase de câblage (coordination prestataires, matrice de brassage), phase de configuration (VLANs, politiques Wi-Fi, provisioning via Meraki Cloud), et phase de validation (tests de charge, rollback plan, acceptance testing). Chaque sprint avait un périmètre clairement délimité et un critère de sortie explicite.

Centralisation parc → : organisation inter-équipes

Ce projet a été géré entièrement en méthode Agile via Jira (création et suivi des tickets, itérations créées pour chaque changement de besoin ou évolution du projet). La complexité organisationnelle venait de coordonner deux équipes aux référentiels différents : chaque décision de data mapping devait être validée des deux côtés avant intégration, ce qui demandait une organisation assez rigoureuse pour ne pas perdre de temps en allers-retours.

Points clés

Extension réseau : déploiement par sprints

Quatre phases structurées, suivi Jira avec périmètre délimité et critères de sortie explicites, zéro coupure en production.

ServiceNow CMDB : coordination bi-équipe

Gestion Agile via Jira, arbitrages de data mapping validés des deux côtés avant intégration, rigueur pour éviter les allers-retours.

Autocritique

Mon organisation est forte sur les projets où le périmètre est défini d'avance. Elle est plus fragile quand les priorités changent en cours de route. J'ai institué un rituel de re-priorisation hebdomadaire, mais c'est encore un axe de vigilance.

L'autre limite : j'ai tendance à sous-estimer les tâches de coordination (les échanges avec les autres équipes, les validations en attente, les dépendances externes) par rapport aux tâches techniques pures. Ces "temps morts" apparents sont en réalité du temps de travail qu'il faut intégrer dans la planification.

Ce que je conseillerais : cartographier les dépendances avant les tâches. Sur un projet multi-équipes, les délais viennent rarement des tâches techniques elles-mêmes, ils viennent des temps d'attente de validation, des disponibilités, des allers-retours. Prévoir ça dans le sprint évite les dérives de planning que personne n'avait anticipées.

L'organisation n'est pas une compétence naturelle pour moi, elle s'est construite par nécessité, au fil des projets, et elle reste un axe de vigilance actif. Dans mon profil, elle joue un rôle de support : elle me permet de livrer sur des sujets complexes, mais elle n'est pas ce qui me définit en tant qu'ingénieur.

Points clés

Fort sur le périmètre défini

Mon organisation est solide quand le périmètre est clair d'avance. Elle est plus fragile quand les priorités changent en cours de sprint.

Sous-estimation de la coordination

Tendance à sous-estimer les tâches de coordination (échanges inter-équipes, validations, attentes) par rapport aux tâches techniques pures.

Mon évolution

Je travaille à affiner ma gestion des priorités en utilisant des frameworks simples : matrice d'Eisenhower pour le triage quotidien, planification à la semaine avec identification des dépendances critiques. L'objectif n'est pas de mettre en place un processus lourd, mais d'avoir des règles de décision claires pour les moments où les priorités entrent en conflit.

À plus long terme, je souhaite développer une compétence en gestion de projet formelle (méthodologie Agile/Scrum en profondeur) pour être en mesure de piloter des projets plus complexes avec des parties prenantes multiples.

Je me forme en autoformation à Scrum via le Scrum Guide et des ressources comme Scrum.org, je prévois de passer la certification PSM I (Professional Scrum Master) avant la fin de mon alternance.

Points clés

Frameworks de priorisation

Matrice d'Eisenhower pour le triage quotidien, planification à la semaine avec identification des dépendances critiques.

Gestion de projet formelle

Objectif : méthodologie Agile/Scrum en profondeur pour piloter des projets complexes avec des parties prenantes multiples.

Réalisations rattachées

Cette compétence s'est exprimée principalement au travers des projets suivants :

Points clés

Extension réseau zéro-coupure

Planification et exécution par phases avec sprints Jira, zéro coupure en production.

Centralisation du parc réseau

Coordination bi-équipe en méthode Agile, arbitrages de data mapping rigoureux.