Des premiers projets modestes, et c’est très bien

Quand la création d’une application devient une description plutôt qu’un projet informatique, on pourrait s’attendre à des idées ambitieuses. En pratique, les premières demandes sont modestes. Elles visent le tableur partagé que personne ne met à jour, la chaîne de courriels où se perdent les demandes, le formulaire papier que quelqu’un recopie le vendredi soir.

C’est une bonne nouvelle. Un premier projet modeste se décrit en une page, se valide en équipe et rend service dès la première semaine d’usage. Nous avons expliqué comment écrire cette page dans Décrire son besoin à l’IA. Cet article regarde plutôt ce que les PME assemblent en premier. Pour chaque application : la douleur d’aujourd’hui, ce qu’elle fait, ce à quoi elle se relie et ce qui reste une décision humaine.

Un portail de demandes pour vos clients

Aujourd’hui, les demandes arrivent par courriel, par téléphone, parfois par message à un collaborateur qui n’est pas au bureau. Le client ne sait pas où en est sa demande. L’équipe ne sait pas qui la traite. Les pièces jointes se perdent dans une boîte de réception.

  • Le client dépose sa demande, joint ses documents et suit son statut sans appeler.
  • Chaque demande atterrit dans un seul dossier, avec son origine, son heure et son responsable.
  • Une information manquante déclenche une question ciblée au client, pas un aller-retour de courriels.

Le portail se relie à la gestion des clients, aux devis et aux tickets. Une demande devient un devis ou un ticket sans être ressaisie, et l’historique du client reste complet.

Le suivi des interventions et du planning sur le terrain

Les équipes de terrain vivent avec un planning sur tableau blanc, des bons d’intervention papier et des photos envoyées par message. Quand un client demande où en est son intervention, il faut appeler le technicien. Quand la facture part, elle part tard, parce que la preuve de fin de chantier manque.

  • Les demandes d’intervention, les sites et les équipements concernés sont rassemblés dans un même dossier.
  • La disponibilité des techniciens est visible, et chaque intervention est affectée à une personne et à un créneau.
  • Le technicien clôture sur place, avec photos, signature et remarques, et cette preuve déclenche la préparation de la facture.

L’application se relie au planning et à la facturation. Une intervention clôturée devient une facture prête à être vérifiée. La planification reliée est décrite sur la page Neoo Scheduling.

La règle humaine : réaffecter un technicien sur un site critique est une décision validée par un responsable, jamais une réorganisation automatique.

Un tableau de bord qui lit les vrais chiffres

Beaucoup de PME pilotent avec un tableau de bord construit à la main, une fois par mois, à partir d’exports recopiés. Le jour où il est prêt, il est déjà en retard. Et quand deux chiffres se contredisent, personne ne sait lequel croire.

  • Ventes, marge, trésorerie, factures en retard et tickets ouverts sont lus dans le système relié, pas ressaisis.
  • Chaque chiffre renvoie aux lignes qui le composent : le devis, la facture, le ticket.
  • Un écart par rapport à la période précédente ou à l’objectif est signalé, avec son contexte.

Le tableau de bord se relie à la finance, aux ventes et au support. Il n’ajoute pas une nouvelle source de chiffres, il lit celle qui existe, celle que Neoo Finance tient à jour. Pourquoi ces chiffres naissent dans les opérations, nous l’expliquons dans La marge se décide dans les opérations.

Un chiffre qui étonne mérite une question à une personne, pas une correction automatique.

La règle humaine : un écart déclenche une question à quelqu’un, jamais une correction automatique. Le tableau montre, la personne interprète.

Un flux d’approbation et de suivi des devis

Un devis se prépare dans un document, se valide par un message, part par courriel, puis attend. Qui l’a relancé ? Quelle remise a été accordée ? Le commercial le sait, parfois. Le reste de l’entreprise l’apprend quand la commande arrive, ou n’arrive pas.

  1. Préparer

    Le devis est préparé à partir des données du client et des tarifs en vigueur, sans recopie.

  2. Approuver

    Au-dessus d’un seuil, le devis passe par une approbation avant envoi. En dessous, il part directement.

  3. Envoyer et suivre

    Le client reçoit le devis, et l’équipe voit s’il a été ouvert, accepté ou laissé sans réponse.

  4. Relancer et convertir

    Les relances sont préparées à la date convenue. Un devis accepté devient une commande, puis une facture.

Le flux se relie à la gestion des clients, aux commandes et à la facturation. Il applique les trois garde-fous décrits dans Automatiser sans retirer la décision humaine : un seuil, une validation, une trace.

La règle humaine : une remise au-dessus du seuil demande une approbation. L’application la prépare et la présente, une personne la donne.

Un registre des équipements et des contrats

Pour un prestataire informatique ou une entreprise de maintenance, la connaissance du parc client vit souvent dans la tête d’un technicien et dans quelques fichiers. Un contrat arrive à échéance sans que personne ne l’ait vu. Un équipement en fin de vie tombe en panne un lundi matin, et l’urgence remplace la prévention.

  • Chaque client dispose d’une fiche de parc : équipements, versions, garanties, contacts.
  • Les contrats et leurs échéances de renouvellement sont visibles et préparés à l’avance.
  • Les incidents sont rattachés à l’équipement concerné, avec leur historique.
  • Les alertes sont préparées avant que le problème ne devienne une urgence.

Le registre se relie aux tickets, aux contrats et à la facturation. Rattaché à la supervision, il transforme un signal technique en action préparée, comme décrit dans Voir un incident avant qu’il ne devienne une urgence. Le fonctionnement de la supervision est détaillé sur la page Neoo Monitoring.

La règle humaine : aucune action silencieuse sur l’infrastructure d’un client. Une intervention est annoncée, approuvée et tracée.

Dans Neoo

Dans Neoo, ces applications sont assemblées par Neoo Forge, l’atelier qui assemble vos applications avec l’IA. Vous décrivez le besoin avec vos mots, Forge propose les écrans, les règles et les automatisations, et votre équipe valide avant la mise en service. Vous pouvez le voir sur la page Neoo Forge.

Chaque application vit sur le même socle que vos clients, vos factures et vos tickets. Elle est reliée dès le premier jour : pas d’export, pas de double encodage, pas de nouvel outil isolé à maintenir.

Murphy, l’agent qui veille, s’occupe de la partie vivante : il prépare les questions au client, les relances de devis et les alertes de renouvellement, demande une approbation quand la règle l’exige et garde une trace de chaque action. Les règles humaines de cet article deviennent des réglages, pas des rappels affichés au mur.

Et si l’une de ces applications devient un vrai savoir-faire, elle peut devenir un produit. Un portail de demandes conçu pour vous peut être proposé à d’autres entreprises de votre secteur. Nous décrivons ce chemin dans De l’idée au logiciel que vous vendez. Pour la méthode de départ, relisez Créer une application métier sans coder.

Questions fréquentes

Par laquelle commencer ?

Par celle qui remplace le contournement manuel le plus pénible : le tableur que tout le monde évite, la chaîne de courriels qui perd des demandes. Choisissez un périmètre avec peu de personnes impliquées et un résultat facile à constater.

Ces applications peuvent-elles fonctionner ensemble ?

Oui. Elles vivent sur le même socle et partagent les mêmes clients, les mêmes contrats et les mêmes données. Une demande du portail peut devenir une intervention, puis une facture, sans ressaisie.

Peut-on les adapter à notre vocabulaire et à nos règles ?

Oui. Vous décrivez l’application avec vos mots : vos statuts, vos seuils, vos responsables. L’IA assemble, votre équipe valide, et vous ajustez quand votre façon de travailler évolue.