Pour les associations, les écoles et les projets d'intérêt collectif

Des outils numériques pour celles et ceux qui agissent pour les autres.

Je m'appelle Kévin. Kedo est mon surnom, formé à partir de Kévin Doucenet. Je suis seul derrière ce site.

Je conçois bénévolement des sites, des applications et des outils numériques pour des associations, des écoles, des collectifs et des projets humains qui peuvent réellement aider des personnes.

Mon temps de conception et de développement est offert. Lorsqu'un nom de domaine, un hébergement, une licence ou un service externe est réellement nécessaire, je l'explique avant toute décision et je cherche d'abord l'option la plus simple, durable et économique.

Me présenter votre besoinComprendre ma démarche
Mon temps est offertAucun abonnement imposéVous gardez la maîtrise de votre outil

Les projets que je peux étudier

ASBL et associations

Associations sans but lucratif, associations de fait, collectifs citoyens et projets culturels, sportifs ou environnementaux.

Écoles et collectifs

Équipes pédagogiques, structures de formation, étudiants ou chercheurs portant un projet d'intérêt collectif concret.

Services d'aide

Services sociaux, projets de santé non médicale, groupes qui soutiennent des publics fragilisés ou des initiatives solidaires.

Initiatives d'intérêt général

Personnes seules portant un projet clairement tourné vers le bien commun, ou toute autre forme à expliquer dans le formulaire.

Le statut juridique n'est pas le seul critère. Je regarde surtout l'utilité du projet, les personnes qu'il aide, sa faisabilité et la possibilité de construire quelque chose de durable.

Une personne, pas une agence

Il n'y a pas une équipe commerciale, un service client et dix développeurs derrière Kedo. Il y a moi, Kévin, devant un écran, avec l'envie d'utiliser ce que je sais faire là où cela peut être utile.

Cela a des avantages : vous parlez directement à la personne qui comprend le besoin et construit la solution. Cela implique aussi une limite honnête : je ne peux pas accepter tous les projets, tout faire en même temps ni garantir les délais d'une agence complète.

Je préfère accepter moins de projets, bien comprendre leur utilité et construire quelque chose de réellement utilisable.

KEDO : un surnom devenu une boussole

Kedo était d'abord mon surnom. Avec le temps, ces quatre lettres ont fini par résumer la manière dont j'ai envie de construire.

Knowledge • Equality • Development • Openness

Le savoir • l'égalité • le développement • l'ouverture

Knowledge, le savoir

Le savoir est un bien commun. Plus il circule, plus il permet aux personnes de comprendre, de décider et d'agir par elles-mêmes.

Je documente ce que je construis et j'évite autant que possible les systèmes que personne d'autre ne peut reprendre.

Equality, l'égalité

Une petite association ne devrait pas être condamnée à de mauvais outils simplement parce qu'elle n'a pas le budget d'une entreprise.

L'égalité, ici, consiste à rendre accessibles des capacités techniques qui restent trop souvent réservées à celles et ceux qui peuvent payer.

Development, le développement

Développer ne signifie pas empiler des fonctionnalités. Cela signifie comprendre un problème, choisir une solution réaliste, la tester avec les personnes concernées et l'améliorer sans perdre de vue l'objectif.

Openness, l'ouverture

Un outil utile doit pouvoir être expliqué, adapté et repris. J'essaie de limiter la dépendance à une personne, à un fournisseur ou à un abonnement évitable.

L'ouverture, c'est aussi rester curieux, écouter les usages réels et accepter qu'une idée évolue au contact du terrain.

Je ne veux pas créer pour posséder. Je veux créer pour rendre possible.
Parce qu'une bonne idée ne devrait jamais mourir faute d'argent.

Vous n'avez pas besoin de savoir quel logiciel il vous faut

Vous pouvez arriver avec une idée précise, un vieux fichier Excel, un processus qui prend trop de temps ou simplement une phrase comme : « Nous perdons les inscriptions », « Personne ne sait mettre le site à jour » ou « Nous recopions toujours les mêmes informations ».

Je commence par comprendre le problème, les personnes concernées et ce qui existe déjà. Le bon résultat n'est pas forcément une grosse application. Cela peut être un formulaire mieux pensé, une automatisation, une page claire ou une petite interface que l'équipe peut utiliser sans formation.

Ce que je peux construire

Présence en ligne

  • Site vitrine
  • Présentation d'un projet ou d'un événement
  • Pages de campagne
  • Annuaire ou catalogue simple
  • Espace de ressources
  • Blog ou actualités faciles à maintenir

Inscriptions et organisation

  • Formulaire d'inscription
  • Gestion de participants
  • Réservation simple
  • Billetterie adaptée
  • Génération de confirmations, billets ou documents PDF
  • Suivi de demandes

Outils internes

  • Petit espace d'administration
  • Tableau de bord
  • Gestion simple de contacts, membres, activités ou documents
  • Remplacement d'un tableur devenu ingérable
  • Centralisation d'informations dispersées

Automatisation

  • Emails de confirmation
  • Création automatique de documents
  • Synchronisation simple entre outils
  • Suppression de recopies manuelles
  • Notifications et rappels raisonnables

IA encadrée

  • Recherche dans des contenus
  • Aide à la rédaction
  • Classification ou extraction structurée
  • Génération contrôlée de documents
  • Prototype permettant de tester une idée avant d'investir

Je ne propose pas de l'IA parce que le mot est à la mode. Je l'utilise uniquement lorsqu'elle apporte un gain réel, peut être vérifiée et ne met pas inutilement en danger des données sensibles.

Comment se passe un projet ?

  1. Vous expliquez le besoin

    Vous me dites qui vous êtes, qui vous aidez, ce qui pose problème aujourd'hui et ce que vous aimeriez améliorer. Une demande imparfaite vaut mieux qu'un faux cahier des charges rempli de mots techniques.

  2. Je vérifie l'adéquation

    Je regarde l'utilité, la faisabilité, le temps nécessaire, les risques et ma disponibilité. Je peux refuser, proposer de réduire le périmètre ou orienter vers une autre solution.

  3. Nous cadrons une première version

    Nous cherchons le plus petit outil qui résout déjà une vraie partie du problème. Les fonctionnalités secondaires viennent ensuite, pas avant.

  4. Je construis et je montre rapidement

    Je privilégie un prototype ou une première version visible tôt. Il est plus facile de réagir à quelque chose de concret qu'à un document abstrait de cinquante pages.

  5. Les personnes concernées testent

    L'outil doit être testé par celles et ceux qui l'utiliseront réellement. Les retours de terrain comptent davantage qu'une démonstration parfaite sur mon ordinateur.

  6. Je transmets

    Je livre les accès, les informations utiles et une documentation proportionnée au projet. L'objectif est que la structure garde la maîtrise et puisse faire reprendre l'outil si nécessaire.

Ce que « gratuit » signifie vraiment

Je ne facture pas mon temps de conception et de développement pour les projets associatifs que j'accepte dans ce cadre.

Cela ne rend pas magiquement gratuits tous les services qui existent autour d'un site ou d'une application. Un nom de domaine, un hébergement, une adresse email, une API, du stockage ou un volume important d'IA peuvent avoir un coût demandé par un fournisseur externe.

Dans ce cas :

  • je l'annonce avant toute décision
  • j'explique à quoi sert le coût
  • je cherche d'abord une solution gratuite ou peu coûteuse
  • le compte est, autant que possible, créé au nom de la structure
  • je n'ajoute aucune marge cachée
  • aucune dépense n'est engagée sans accord

Un outil utile ne doit pas devenir une laisse

Je cherche à éviter qu'une association dépende de moi pour chaque petite modification.

Selon le projet, cela signifie :

  • créer les comptes importants au nom de la structure
  • transmettre les accès de manière sécurisée
  • fournir le code source lorsque c'est possible et pertinent
  • expliquer l'hébergement et les coûts
  • prévoir une administration simple
  • documenter les opérations importantes
  • permettre la reprise par un autre développeur

Certaines briques externes ont leurs propres licences ou limites. Elles doivent être identifiées clairement plutôt que cachées derrière une promesse d'indépendance absolue.

Comment les projets sont choisis

Je ne peux pas accepter tous les projets. Un refus ne signifie pas que l'idée n'a pas de valeur. Il peut simplement signifier que le besoin dépasse mes moyens, que le moment n'est pas le bon ou qu'une autre forme d'aide serait plus adaptée.

Critères positifs

  • Impact collectif clair
  • Problème réel et identifiable
  • Bénéficiaires définis
  • Participation de la structure
  • Périmètre compatible avec une personne seule
  • Respect des personnes, de la loi et des données

Ce que je ne promets pas

Je ne promets pas de tout faire, ni de tout faire vite.

Je ne suis pas disponible comme une agence avec une permanence continue. Je ne peux pas garantir qu'un projet bénévole sera traité à une date précise avant de l'avoir étudié. Je ne construis pas de systèmes critiques sans les compétences, les partenaires ou le cadre de sécurité nécessaires.

En revanche, je promets d'être clair sur ce que je peux faire, de ne pas cacher les limites et de ne pas retenir un projet dans une dépendance inutile.

Commençons par le problème, pas par la technologie

Présentez-moi votre structure, les personnes que vous aidez et ce qui vous fait perdre du temps ou vous empêche d'avancer. Vous n'avez pas besoin d'avoir déjà trouvé la solution.

Présenter mon projet

Le formulaire prend environ cinq minutes. Les champs détaillés sont facultatifs lorsque vous n'avez pas encore la réponse.