par Camille Fontaine 
Prendre la direction technologique d’une entreprise ne consiste pas à produire une vision en cent jours : il faut d’abord rendre visible ce qui fragilise l’organisation et choisir les arbitrages qui comptent. Dette technique, cybersécurité et usages de l’IA doivent alors être traités comme trois sujets de pilotage interdépendants, au service de la continuité d’activité, de la conformité et de la croissance.
Écouter, aligner, agir : une trajectoire en trois temps
Les cent premiers jours ne sont pas le moment d’imposer une réorganisation générale ni de lancer une succession de projets visibles. Le CTO doit d’abord comprendre l’entreprise telle qu’elle fonctionne réellement : ses produits, ses contraintes économiques, ses dépendances technologiques, ses habitudes de décision et ses zones de fragilité.
Les trente premiers jours peuvent être consacrés à une phase d’immersion structurée. Les échanges avec les équipes IT, les responsables métiers, la DAF, les fonctions juridique et sécurité, ainsi que la direction générale, permettent de confronter les représentations. L’objectif n’est pas seulement de recenser les outils et les projets en cours : il est de repérer les écarts entre la stratégie affichée, les priorités business et la réalité opérationnelle.
Entre le trentième et le soixantième jour, le CTO doit transformer ce diagnostic en priorités. Certaines difficultés sont déjà connues de tous : une application instable, des délais de livraison trop longs, des incidents récurrents, une dépendance excessive à un prestataire ou des données difficiles à exploiter. Résoudre une ou deux de ces situations crée de la confiance, à condition de ne pas confondre quick win et solution superficielle.
À l’issue des cent jours, le comité de direction doit disposer d’une lecture claire : quels risques doivent être traités immédiatement, quels investissements sont nécessaires, quels projets doivent être ralentis ou arrêtés, et quelle trajectoire technologique soutiendra les objectifs de l’entreprise à un an puis à trois ans. Cette feuille de route doit être exprimée en conséquences business : continuité de service, capacité à livrer, maîtrise des coûts, conformité, qualité de l’expérience client ou vitesse d’innovation.
Faire de la dette technique un objet de décision
La dette technique est souvent réduite à du code ancien ou mal documenté. C’est trop limité. Elle peut aussi prendre la forme d’une architecture devenue rigide, de dépendances logicielles obsolètes, de processus manuels, d’applications redondantes, de données incohérentes ou d’une connaissance concentrée chez quelques personnes.
Certaines dettes sont assumées. Une entreprise peut, par exemple, accepter un compromis technique pour lancer rapidement un produit, tester un marché ou répondre à une exigence réglementaire. Le problème apparaît lorsque ce compromis n’est ni documenté, ni réévalué, ni financé. La dette devient alors subie : les équipes consacrent davantage de temps à contourner les limites du système qu’à créer de la valeur.
Le diagnostic doit relier la dette à ses effets concrets. Quels composants provoquent des incidents ? Quels outils ralentissent la mise en production ? Où se trouvent les dépendances critiques à une technologie, un fournisseur ou une personne ? Quels produits sont coûteux à faire évoluer ? Quels écarts de sécurité ou de conformité sont liés à l’obsolescence technique ?
Des outils d’analyse de code peuvent aider à objectiver certains sujets, notamment la maintenabilité, les vulnérabilités connues ou la couverture des tests. Mais ils ne remplacent pas une analyse d’architecture et d’usage : une application peut présenter peu d’anomalies dans son code tout en restant coûteuse, inutilement complexe ou mal intégrée au système d’information.
Le CTO doit ensuite rendre les arbitrages explicites. Il n’existe pas de seuil universel de dette technique à partir duquel un système deviendrait automatiquement « sain » ou « critique ». Un ratio ou un score n’a de valeur que s’il est interprété au regard de la criticité métier, de la fréquence des incidents, du coût de maintenance et de la capacité de l’entreprise à évoluer.
La réponse la plus valable n’est généralement pas la réécriture totale. Les projets de remplacement « Big Bang » concentrent les risques, mobilisent longtemps les équipes et peuvent faire disparaître des règles métier mal documentées. Une approche progressive est souvent préférable : sécuriser les composants les plus critiques, isoler les dépendances, moderniser par étapes et intégrer le remboursement de la dette dans la planification normale des produits.
Construire une cybersécurité résiliente, pas seulement conforme
La cybersécurité ne peut pas être traitée comme un sujet séparé de l’activité technologique. Elle concerne les applications, les identités, les données, le cloud, les prestataires, les postes de travail et les processus métier. Pour un nouveau CTO, la première urgence consiste à savoir ce qui est réellement exposé et ce qui serait le plus dommageable en cas d’incident.
Une cartographie de la surface d’attaque doit inclure les domaines et sous-domaines, les interfaces API, les environnements cloud, les applications accessibles depuis l’extérieur, les comptes à privilèges et les flux de données sensibles. Elle doit également chercher ce qui échappe au pilotage central : services achetés directement par une direction, outils collaboratifs non validés, comptes non répertoriés ou environnements de test devenus permanents.
Cette phase doit être complétée par une analyse de risques. En France, la méthode EBIOS Risk Manager proposée par l’ANSSI permet notamment de raisonner à partir des événements redoutés, des sources de risque, des scénarios d’attaque et des mesures de sécurité à retenir. Elle évite de réduire la sécurité à une simple liste de contrôles techniques. ANSSI, EBIOS Risk Manager
Le CTO doit aussi clarifier le cadre réglementaire qui s’applique à son entreprise. La directive européenne NIS2 impose, pour les entités concernées, des mesures de gestion des risques cyber et des obligations de notification d’incidents ; sa déclinaison dépend ensuite du droit national. Le règlement DORA vise quant à lui la résilience opérationnelle numérique du secteur financier. Union européenne, directive NIS2 ; Union européenne, règlement DORA
Le tableau de bord remis au COMEX doit rester lisible. Il peut suivre, par exemple, la couverture de l’authentification multifacteur, la protection des postes et serveurs, le délai de correction des vulnérabilités critiques, l’inventaire des comptes à privilèges, les sauvegardes testées, les incidents significatifs et l’état des plans de continuité ou de reprise. L’enjeu est moins de produire beaucoup d’indicateurs que de montrer les risques, les décisions attendues et les progrès mesurables.
Passer des expérimentations IA à une feuille de route utile
L’IA générative a souvent fait entrer l’entreprise par les usages individuels : rédaction, synthèse, recherche, production de contenus ou assistance au développement. Le risque est de multiplier les expérimentations sans données maîtrisées, sans critères de succès et sans capacité à passer en production.
Le CTO doit donc organiser une phase de découverte des cas d’usage avec les métiers. La bonne question n’est pas :
« Où mettre de l’IA ? » Elle est :
« Quel problème métier important peut être amélioré, avec quelles données, quels risques et quels bénéfices mesurables ? »
Une matrice simple peut aider à prioriser les cas d’usage selon quatre critères : impact business, faisabilité technique, qualité et disponibilité des données, niveau de risque. Un usage à fort impact mais reposant sur des données non fiables peut nécessiter un travail préalable de gouvernance. À l’inverse, un cas d’usage modeste mais facilement déployable peut être utile pour acculturer les équipes et démontrer une valeur rapidement.
Le choix entre achat, développement interne et partenariat doit être assumé. Une solution SaaS peut accélérer un usage standardisé ; un développement interne peut être pertinent lorsqu’un avantage concurrentiel dépend directement des processus, des données ou de l’intégration au système existant. Dans tous les cas, il faut regarder au-delà de la démonstration : sécurité, réversibilité, localisation et traitement des données, capacité d’intégration, coûts récurrents, supervision et dépendance au fournisseur.
La gouvernance des données est le socle de cette stratégie. Les collaborateurs doivent savoir quelles informations peuvent être utilisées dans un outil d’IA, lesquelles nécessitent un environnement contrôlé, et lesquelles ne doivent jamais être saisies dans un service non autorisé. Une interdiction globale pousse fréquemment les usages hors du cadre officiel ; une absence de règle produit le même effet avec moins de visibilité.
Le règlement européen sur l’intelligence artificielle, l’AI Act, est entré en vigueur le 1er août 2024 et est devenu largement applicable le 2 août 2026, avec un calendrier spécifique pour certaines dispositions. Il impose une approche fondée sur le niveau de risque et comprend notamment des exigences relatives à la maîtrise de l’IA, à la transparence et aux systèmes à haut risque. Commission européenne, AI Act
Enfin, industrialiser l’IA ne se limite pas à choisir un modèle. Il faut prévoir la qualité des données, les droits d’accès, l’évaluation des résultats, le suivi des coûts, la cybersécurité, la maintenance, la conduite du changement et la responsabilité de validation humaine. Un comité transverse réunissant IT, métiers, sécurité, juridique et conformité peut suffire au démarrage ; un centre d’excellence devient pertinent lorsque le portefeuille de cas d’usage et les besoins d’accompagnement se structurent.
Le CTO comme partenaire de transformation
Au terme de ses cent premiers jours, le CTO ne doit pas être jugé sur le nombre de nouveaux outils annoncés. Sa valeur réside dans sa capacité à rendre l’entreprise plus lisible, plus résiliente et plus capable d’exécuter sa stratégie.
Maîtriser la dette technique, améliorer la cybersécurité et cadrer les usages de l’IA relèvent d’un même travail : choisir les risques à réduire, les capacités à construire et les investissements à assumer. C’est à cette condition que la technologie cesse d’être perçue comme un centre de coût opaque et devient un levier de décision, de confiance et de croissance.