Compétences
La persévérance en développement logiciel est la capacité à continuer une investigation lorsque le premier correctif ne traite que le symptôme, que la documentation ne couvre pas le cas rencontré ou qu'une solution impose plusieurs cycles d'essai. Elle associe endurance, méthode et mémoire du chemin parcouru : reproduire le défaut, formuler une hypothèse, recueillir des traces, modifier une seule variable utile, vérifier le résultat et conserver ce qui a été appris. Sans cette discipline, la ténacité peut devenir une répétition coûteuse des mêmes tentatives.
Je distingue donc la persévérance de l'obstination. Continuer est pertinent lorsque chaque itération réduit l'incertitude ou rapproche d'un critère observable. Changer d'approche est préférable lorsque l'architecture, le périmètre ou l'hypothèse de départ ne tient plus. Cette compétence est particulièrement importante dans les migrations, les visualisations sur mesure et les règles métier complexes, où une solution apparemment fonctionnelle peut encore cacher une erreur de données, de sécurité ou d'interprétation.
Après le correctif critique de décembre 2025, les recherches ont révélé plusieurs vulnérabilités supplémentaires dans les React Server Components, dont une encore corrigée le 26 janvier 2026. Cet épisode illustre qu'un problème complexe exige des vérifications et des itérations jusqu'à traiter aussi les variantes du défaut initial.
Consulter la source : ReactLa migration d'Odoo 16 vers Odoo 19 ne pouvait pas être exécutée en une seule opération. Chaque passage vers les versions 17, 18 puis 19 faisait apparaître de nouvelles erreurs dans les modules internes, les extensions tierces, les vues XML ou les personnalisations Studio. J'ai dû lire les logs d'Odoo.sh, retrouver l'héritage ou le champ devenu invalide dans le code source, adapter la personnalisation, relancer la migration et vérifier que le correctif n'introduisait pas une autre régression. Certaines extensions officiellement mises à jour restaient défectueuses et nécessitaient encore une correction locale ou une migration manuelle.
Résultat — La migration a abouti après plusieurs mois avec les données et les fonctions utiles préservées. La persévérance n'a pas consisté à relancer aveuglément : chaque erreur résolue enrichissait l'inventaire et rendait la migration suivante plus prévisible.
Dans CAP2vie, la trajectoire devait représenter des périodes exactes ou estimées, cinq dimensions et deux modes de lecture, puis rester cohérente lorsque l'enquêteur corrigeait une réponse depuis le formulaire ou directement depuis le graphique. Ma première intégration reposait sur un algorithme de résolution insuffisamment approfondi. Le pont entre les données du questionnaire et D3.js est devenu la partie la plus retravaillée du projet. Plutôt que d'empiler des exceptions, j'ai revu la transformation des réponses, la construction des intervalles et la manière dont les modifications revenaient vers l'état partagé.
Résultat — Le prototype a livré une visualisation reliée au questionnaire, corrigeable depuis deux points d'entrée et utilisable en démonstration. Cette expérience m'a appris que persévérer peut exiger de reconstruire une partie de l'architecture plutôt que de protéger le premier code écrit.
Le calcul de marge sur les factures comptables n'existait pas sous la forme attendue par l'entreprise. Il fallait rapprocher les écritures, les lignes de facture et les règles comptables tout en respectant le moteur interne d'Odoo. Les premières versions ont nécessité de nombreux échanges avec la comptabilité et des lectures du code source pour comprendre quels événements recalculaient les valeurs. Après la migration, un défaut autour des marges de factures a encore montré qu'un résultat correct dans un scénario ne suffisait pas à couvrir toutes les données réelles.
Résultat — La direction dispose d'indicateurs de marge pendant l'exercice au lieu d'attendre uniquement les analyses de clôture. Je conserve néanmoins ce calcul comme un chantier perfectible : la valeur livrée est réelle, mais sa complexité impose encore des mesures de performance et des cas de test supplémentaires.
Les éléments de preuve décrivent des épisodes précis. Cette synthèse les replace dans les études de cas complètes : le contexte, ma contribution et le résultat permettent d'observer ce que cette compétence a rendu possible, avec le niveau de prudence nécessaire sur chaque résultat.
J'estime avoir un niveau avancé parce que je reste mobilisé sur des problèmes longs, incertains et techniquement ingrats jusqu'à obtenir un résultat exploitable. Je sais reprendre une hypothèse, lire le code d'un framework et accepter de réécrire. Mon axe de progrès est d'instrumenter plus tôt cette persévérance avec des scénarios de test, des mesures et un journal de décisions afin de réduire le nombre d'itérations tardives.
Elle est essentielle à ma spécialisation Odoo, où une erreur peut provenir du code interne, d'un module tiers, d'une personnalisation en base ou d'une donnée métier. Elle compte aussi dans le front-end et la visualisation, car un rendu plausible ne prouve pas que l'information représentée est juste.
Je conseille de définir ce que la prochaine tentative doit apprendre avant de la lancer. Si elle ne produit aucune information nouvelle, il faut changer de méthode : réduire le cas, ajouter des traces, demander une expertise métier ou revoir l'architecture. La persévérance devient professionnelle lorsqu'elle diminue l'incertitude au lieu de seulement consommer du temps.
Conserver cette endurance tout en réduisant le temps nécessaire pour reconnaître une mauvaise piste. Je veux progresser dans la formulation d'hypothèses, l'automatisation des reproductions et l'usage de métriques qui permettent d'arrêter plus vite une approche non rentable.
