Ma définition
Je le définis comme la faculté d’évaluer objectivement une situation, un besoin ou un choix technologique, tout en pesant le pour et le contre avant de se lancer tête baissée dans le développement. L’esprit critique reste plus que jamais le dernier rempart humain pour garantir la sécurité, l’éthique et la pertinence d’une application.
Cela comprend également le fait de savoir faire face à une pression de délai ou à l’enthousiasme immédiat pour une technologie nouvelle qui n’a pas encore fait ses preuves dans le contexte concerné.
Mes éléments de preuve
Dans ma veille technologique continue, j’intègre l’IA comme un assistant technique à part entière. J’ai appris à structurer des « prompts » complexes en fournissant du contexte, des contraintes et des exemples pour obtenir des morceaux de code précis ou pour analyser des logs d’erreurs denses.
Je peux prendre également de mes activités à CGI. En effet, mon arbitrage systématique entre solutions natives (« Out-Of-The-Box ») et développement spécifique repose directement sur cette capacité d’analyse : évaluer si la valeur métier réellement ajoutée par un développement custom justifie la dette technique qu’il génère mécaniquement sur les futures montées de version de la plateforme SaaS, un calcul qui ne se limite jamais au seul confort de développement immédiat.
Résultat : Pour le projet PMT, un projet finalisé avec aisance malgré deux incidents majeurs, grâce au changement de méthode décidé à temps plutôt que subi.
Pour mon projet de veille technologique, un gain de productivité réel et mesurable sur les tâches répétitives et le débogage d’environnements inconnus, sans dérive vers une confiance aveugle dans les outils d’IA.
Mon autocritique
Cette compétence est en constante évolution. En effet, elle se nourrit d’une remise en question perpétuelle face au déferlement incessant des innovations technologiques. Qu’il s’agisse de l’émergence de nouveaux frameworks, de la puissance des outils d’IA ou de l’évolution des usages numériques, notre capacité de discernement devient un défi de chaque instant.
Le risque est de succomber à la « hype » technique au détriment de l’efficacité réelle. Mon conseil personnel est de toujours faire un pas de côté : avant de coder une fonctionnalité demandée, l faut se demander pourquoi on nous la demande, et ne pas hésiter à mobiliser sa veille informationnelle pour challenger une décision technique avant de s’y engager pleinement.
Mon évolution
Il est désormais indispensable pour moi d’appliquer systématiquement cette capacité d’analyse à des exercices plus formels d’ingénierie logicielle plutôt que de la mobiliser uniquement de façon réactive face à un incident déjà survenu, comme cela a été le cas sur le projet PMT réalisé dans le cadre de la formation avec l’ISCOD lors du pivot méthodologique en cours de projet.
À terme, je souhaite formaliser cette démarche critique sous une forme plus systématique et proactive. Ce que j’entends par là, c’est de tenir pour chaque projet significatif, une courte liste de scénarii techniques posées en amont (choix de framework, d’architecture, de méthode de gestion de projet) avec un point de vérification à mi-parcours, plutôt que de laisser la remise en question survenir uniquement lorsqu’un incident majeur l’impose de fait.
C’est une évolution vers un esprit critique préventif plutôt que correctif, qui me semble être la marque d’une réelle maturité d’ingénieur.
Enfin, je désire également muscler cette compétence sur le volet éthique et sécurité, au-delà du seul choix d’architecture, à savoir questionner plus systématiquement l’usage qui sera fait des données manipulées par une application (comme celles des étudiants sur Dolibarr ou des tickets clients sur ServiceNow), et non plus seulement sa performance ou sa maintenance technique.
C’est une dimension que mes projets actuels, menés dans des contextes de formation ou de démonstration, n’ont pas encore pleinement mise à l’épreuve face à des enjeux réels de conformité réglementaire.