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.
Ces entreprises qui ont « du code ».
Du code, l’or des temps modernes ? 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.
1. Risques sur le fonctionnement
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 l’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 d’un site web ne marche pas…
- Mais personne n’est au courant !
Voilà une perte de crédibilité qu’il serait bon d’éviter, non ?
2. Difficulté de relation avec les développeurs
On a des difficultés à se comprendre entre spécialistes d’un métier et spécialistes de développement informatique.
En dehors de la question du Cahier des Charges que nous abordons ici, 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.
3. 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.
4. 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…
Mais c’est parce que l’infrastructure est totalement surdimensionnée.
Dans ce cas : des surcoûts inutiles.
5. 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.
Mais pas seulement !
Il faut aussi accéder à tout ce qui est nécessaire pour fabriquer l’application à partir des 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.
6. 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 : des composants Javascript 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.