Référent technique, CTO
Que peut vous apporter un référent technique, un CTO à temps partagé ?
La question concerne les entreprises ayant des développements informatiques à leur actif.
Ce sont des entreprises « qui ont du code ». 👨💻
Le code, est-ce l'or des temps modernes ?
Le code, c'est une forme de tuyauterie logique... 😄 Certes, c'est précieux !
En tout cas, comme pour toute denrée précieuse, détenir cette richesse s'accompagne de risques.
Un référent technique gère ces risques.
On peut aussi l'appeler CTO (Chief Technical Officer), ou Architecte digital.
Voici les dangers concernés, selon nous.
(Infographie par Mohammed_hassan sur Pixabay)
- Risques sur le fonctionnement
Est-ce que le système tel qu'il est, fonctionne ? 😅(*)
Est-ce que les données sont sauvegardées ?
Y a t-il un processus éprouvé à suivre en cas de panne de tel ou tel système ?
Est-ce que l'architecture du système va tenir en cas d'augmentation de la charge ?
Est-ce qu'on a un interlocuteur à appeler en face de chaque nature de problème technique ?
Est-ce que tel système, critique pour l'Entreprise, est bien réalisé et documenté ?
Saura t-on le maintenir une fois les développeurs partis ?
(*) Exemple navrant, déjà vu plusieurs fois :
- Le formulaire de contact du site web de l'entreprise ne marche pas…
- Mais personne n'est au courant !
- Voilà une perte de crédibilité qu'il serait bon d'éviter, non ?
- Difficulté de relation avec les développeurs
On a des difficultés à se comprendre entre spécialistes métier et spécialistes de développement informatique.
Cela commence avec les cahiers des charges : le CTO peut aider à les établir, de façon qu'ils soient
- Lisibles par chaque partie
- Suffisamment précis et spécifique
- D'une exigence en rapport avec les moyens mis en oeuvre (pas de lettre ✉️ au père Noël 🎅)
En dehors de la question du cahier des charges, d'autres difficultés peuvent se présenter :
- Alors que le coût initial était modéré, la maintenance est chère
- Le projet est très ralenti depuis le départ d'un développeur vers d'autres horizons
- Le système n'est pas stable 🌩️
- Le système ne répond pas assez rapidement 🐢
- Certaines évolutions prévisibles semblent devenues presque impossibles. 🙅
Le rôle du CTO dans un tel cas est de se faire l'interprète des différentes parties en présence, et de proposer grâce à son expertise, des chemins pour avancer.
- Incertitudes sur l'architecture
En début de projet (ou plus tard…), on peut sécher sur des choix d'architecture 📐.
L'avis d'un professionnel peut alors éclairer, faire apparaître des critères de décision.
Florilège de situations délicates :
- Le prototype, le MVP (minimum viable product) est instable ou lent
- Vous êtes pieds et poings liés avec une technologie, un fournisseur, ou un hébergeur
- Le prestataire vous a vendu telle technologie… pas vraiment appropriée, mais c'était celle qu'il connaissait
- Une des technologies employée est originale ; mais personne ne sait la maintenir.
- Doutes sur la montée en charge
L'architecture choisie va t-elle tenir la charge en fonction de la prévision d'utilisation ?
Les dimensionnants de la charge sont les suivants :
- Nombre d'utilisateurs 🧍🧍🧍🧍🧍🧍🧍🧍🧍🧍
- Durée moyenne d'utilisation ⌚
- Saisonnalité ☀️🍂❄️🌷
- Volume de données utilisés 🚚
- Volume de données transitant par Internet 🌐
- etc.
Dans certains cas, le système tiendra la charge, oui…
Uniquement parce que l'infrastructure est totalement surdimensionnée.
Dans ce cas : ce sont des surcoûts inutiles.
- Méconnaissance des codes sources, de la doc
Pour pouvoir être maître d'une application, d'un site web…
Il est nécessaire de pouvoir accéder aux codes sources 📑.
Indispensable... Mais pas seulement !
Il faut aussi accéder à tous les outils nécessaires 🧰 pour fabriquer l'application à partir des codes sources.
Si le système est utilisé dans le monde réel, il faut aussi un environnement de test.
Un environnement de test qu'est-ce que c'est ?
C'est un système (application, site) qui marche « comme le vrai » mais qui ne dérange personne quand il tombe en panne.
- Questions de propriété intellectuelle
Votre application : Qui est propriétaire des codes sources ? Qui détient les droits d'auteur ?
Est-ce que vous utilisez des licences contaminantes ?
Exemple : votre appli dispose de composants graphiques de très belle qualité, dont vous vous apercevez après coup qu'il faut débourser quelques centaines ou milliers d'euros 💶 chaque année pour continuer à les utiliser.
