Catégorie : Uncategorized

Un site qui ne se met plus à jour, une application interne que personne ne sait modifier, un prestataire qui ne répond plus aux e-mails. La situation est fréquente et rarement urgente au début : tout fonctionne encore. Elle le devient le jour où il faut changer quelque chose.

Avant de chercher qui pourra reprendre le travail, il y a une étape plus utile : récupérer ce qui vous appartient. Sans cela, n’importe quel intervenant repartira de zéro, et vous paierez cette reconstitution.

Les cinq éléments à récupérer en premier

1. Le nom de domaine. Vérifiez à quel nom il est enregistré et qui reçoit les avis de renouvellement. Un domaine qui expire coupe le site et les e-mails d’un coup, souvent un vendredi soir.
2. L’hébergement. Quel prestataire, quel contrat, payé par qui, et avec quel compte d’administration. Si la facture est au nom de votre ancien prestataire, vous ne contrôlez pas votre site.
3. Les accès d’administration. Un compte à votre nom, avec les droits les plus élevés, sur le site comme sur l’outil. Pas un compte partagé dont le mot de passe circule depuis trois ans.
4. Le code et la configuration, si l’outil a été développé pour vous. Demandez où il est stocké et comment y accéder. Un logiciel sans son code se remplace, il ne se répare pas.
5. Une sauvegarde récente, testée. Une sauvegarde qu’on n’a jamais restaurée est une hypothèse, pas une sécurité.

Ces demandes sont légitimes et se formulent sans conflit : vous demandez l’inventaire de ce que vous payez. Un prestataire sérieux, même occupé, le fournit.

Ce qu’il ne faut pas faire tout de suite

Ne changez pas les mots de passe avant de savoir ce qui s’y connecte. Un site échange souvent avec d’autres services — paiement, envoi d’e-mails, formulaires, sauvegardes automatiques. Couper un accès au hasard casse un flux qui fonctionnait, et personne ne fait le lien trois jours plus tard.

Ne lancez pas non plus la refonte complète par réflexe. Le premier réflexe naturel — « on va tout refaire proprement » — coûte cher et efface l’existant avant de l’avoir compris. Souvent, une remise en état délimitée suffit pendant un an ou deux.

Quand une reprise est raisonnable, et quand elle ne l’est pas

Reprendre l’outil existant est le bon choix quand trois conditions sont réunies : les accès sont récupérables, l’outil rend encore le service attendu, et le problème est identifiable — une fonction cassée, une mise à jour bloquée, une évolution nécessaire.

À l’inverse, mieux vaut ne pas s’acharner quand le code est introuvable, quand la technologie employée n’est plus maintenue, ou quand le besoin a tellement changé que l’outil ne correspond plus à votre activité. Dans ces cas, le remplacement par une solution existante est souvent plus rapide et moins risqué qu’une reprise.

Cette décision — configurer, relier, remplacer ou développer — se prend après avoir regardé l’existant, pas avant. Une phase courte et facturée qui produit un état des lieux exploitable coûte moins cher qu’un projet lancé dans le brouillard.

Ce qui évite de revivre la situation

• Les comptes importants sont au nom de l’entreprise, avec une adresse e-mail qui survit au départ d’une personne.
• Un document court liste vos outils, qui les administre, ce qu’ils coûtent et à quelle date ils se renouvellent.
• Les sauvegardes sont vérifiées une fois, réellement, plutôt que supposées.
• Chaque prestation se termine par la remise des accès et d’une documentation minimale.

Ce n’est pas une question de méfiance envers les prestataires. C’est la même logique que de savoir où sont les clés de vos locaux.

Vous êtes dans cette situation ? Décrivez ce qui bloque à DevThis — ou voyez comment fonctionne le suivi de vos outils et de vos accès.

Un outil sur mesure n’est pas une réponse à chaque gêne informatique. Il devient pertinent lorsqu’une situation se répète, a une conséquence identifiable, et qu’aucune solution existante ne répond correctement au besoin.

Partir d’un exemple, pas d’une liste de fonctions

Le bon point de départ est un cas récent : une information ressaisie plusieurs fois, une intervention terminée mais difficile à suivre, un fichier qui ne permet plus de décider, ou deux logiciels qui ne transmettent pas les bonnes données. Cet exemple permet de comprendre le résultat attendu sans imaginer tout de suite une application complète.

Comparer la réponse la plus simple

Un réglage, une fonctionnalité déjà disponible, un export ou une intégration limitée peuvent parfois résoudre le problème. Le développement sur mesure est justifié lorsqu’il reste un manque précis après cette comparaison : une donnée à rapprocher, une règle métier à appliquer, une interface adaptée à un usage réel.

Définir une première phase

Un projet devient finançable lorsqu’il peut être découpé : résultat visible, ce que ça couvre, ce qu’il faut de votre côté, ce qui n’est pas inclus, et une façon de vérifier que le travail est fait. Cette première phase n’a pas besoin de résoudre tout l’avenir de l’entreprise. Elle doit apporter quelque chose d’utilisable et permettre de décider ensuite de la suite.

Ce qu’un outil ne résout pas à lui seul

Un logiciel n’impose pas une décision, ne remplace pas une règle métier et ne garantit pas que les utilisateurs adopteront un nouveau fonctionnement. Il doit s’intégrer à une responsabilité et à des habitudes que l’entreprise accepte de porter.

Vous avez un exemple concret à examiner ? Contactez DevThis.