Compétences
L'autonomie en ingénierie logicielle ne consiste pas à travailler sans interlocuteur. Elle désigne la capacité à prendre en charge un problème de bout en bout : comprendre le besoin réel, identifier ce qui manque, proposer une stratégie, mesurer les risques, produire une solution vérifiable et rendre compte des décisions prises. Elle suppose aussi de distinguer ce que le développeur peut décider seul de ce qui relève du métier, de la hiérarchie ou d'un fournisseur externe. Une personne autonome avance sans attendre des instructions détaillées, mais elle ne transforme pas l'absence d'encadrement en absence de contrôle.
Cette compétence devient particulièrement visible lorsqu'un système est critique ou mal documenté. Il faut alors chercher dans le code, les journaux, la documentation et les retours des utilisateurs, puis confronter ces sources au lieu de s'arrêter à la première explication plausible. Les assistants de développement peuvent accélérer cette exploration, mais ils ne déplacent pas la responsabilité : je reste chargé de vérifier leurs hypothèses, de protéger les données, d'exécuter les tests et de décider si un changement peut réellement atteindre la production.
OpenAI a lancé l'app Codex pour piloter plusieurs agents sur des tâches longues et parallèles. Cette délégation renforce la valeur de l'autonomie : le développeur doit cadrer le travail, contrôler les changements et rester responsable du résultat.
Consulter la source : OpenAIChez 1UP Distribution, j'ai alerté la direction sur la fin du support d'Odoo 16, puis préparé le passage successif vers les versions 17, 18 et 19. Le périmètre comprenait 16 modules internes, une dizaine de modules tiers, plusieurs centaines de personnalisations Studio, une base PostgreSQL et des intégrations avec le site B2B, les marketplaces et la logistique. Le prestataire qui devait m'assister n'étant finalement pas intervenu, j'ai dû construire l'inventaire, analyser les erreurs dans Odoo.sh, adapter le code, organiser les recettes, préparer le retour arrière et piloter la bascule. Je sollicitais les utilisateurs pour valider leurs processus et le support lorsque la décision ne dépendait pas de moi, mais la cohérence technique d'ensemble restait sous ma responsabilité.
Résultat — La production a été migrée le 6 février 2026 avec environ trois heures d'interruption, sans perte définitive de données. Cette réalisation prouve mon autonomie d'exécution, tout en montrant que j'ai su maintenir des points de validation métier et un scénario de secours.
Pour automatiser la relance des factures impayées, je ne disposais pas d'une spécification technique prête à développer. J'ai reconstitué le processus avec la comptabilité, formalisé les règles et les cas limites dans Jira, séparé les paramètres modifiables de l'algorithme, développé une première version, puis fait évoluer le module à partir des essais sur le staging. J'ai pris en charge le code Python, les vues XML, les droits, l'action planifiée, les tests, le déploiement et la formation. Lorsque les choix engageaient la relation client ou les autorisations, je présentais les options à ma responsable plutôt que de décider à sa place.
Résultat — Le contrôle des factures est désormais quotidien et automatisé, tandis que la comptabilité maîtrise directement les principaux réglages. Environ une demi-journée de travail est économisée chaque semaine sans retirer aux utilisateurs la responsabilité des règles métier.
Sur la refonte du site corporate, j'étais responsable du socle Next.js, du responsive, des animations, des performances, du formulaire et du déploiement, tandis que les graphistes, le marketing et la direction produisaient ou validaient les ressources. Pour ne pas bloquer le projet en attendant chaque décision, j'ai construit les composants réutilisables, l'internationalisation, les fondations SEO et une première chaîne de contact avec des contenus de démonstration clairement identifiés. Je présentais des prototypes lorsqu'ils permettaient un arbitrage réel et je protégeais la future V1 contre l'ajout continu de fonctions non essentielles.
Résultat — La page d'accueil, la page de contact, les composants partagés et la chaîne technique sont déjà présentables alors que le projet est encore en cours. L'autonomie a servi à réduire l'incertitude, pas à contourner les validations éditoriales et visuelles encore nécessaires.
Je situe mon niveau à intermédiaire confirmé. Je peux conduire seul un sujet technique important, entrer dans une base de code inconnue et prendre en charge la production. La migration Odoo montre toutefois ma limite actuelle : j'ai commencé le pilotage personnel trop tard et j'ai sous-estimé le volume des personnalisations Studio. Mon autonomie d'exécution est plus forte que mon anticipation méthodique des grands projets.
Cette compétence structure mon profil parce que je suis souvent le seul développeur interne disponible sur Odoo et que je porte aussi des sujets Next.js et Symfony. Elle me permet de transformer une demande incomplète en plan de travail, mais elle n'a de valeur que si les risques, les dépendances et les décisions restant à valider sont rendus visibles.
Je conseille de définir dès le départ les critères de réussite, les personnes qui valident chaque partie et les conditions d'arrêt ou de retour arrière. Avancer seul devient dangereux lorsque les décisions restent implicites. L'autonomie la plus utile combine initiative, traçabilité, communication et capacité à demander un arbitrage avant que le risque ne se transforme en incident.
Atteindre un niveau avancé en ajoutant à mon autonomie technique une pratique plus systématique du pilotage : registre des risques, jalons observables, décisions consignées, critères d'acceptation et revues d'architecture proportionnées à l'impact.
Je poursuis l'étude des architectures logicielles, de la gestion des migrations et des méthodes de décision technique. Mes prochains projets doivent surtout me faire pratiquer ces outils plus tôt, avant que la complexité soit déjà installée.