# Why you will not find an average rating here

> A rating written by the person it rates proves nothing. Here is what I offer instead, and how to check a technical contractor’s work yourself.

- Source canonique : [https://allaux.fr/en/avis](https://allaux.fr/en/avis)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## A rating I write myself is worth nothing

Many contractor sites display a score out of five, a review count and a few testimonials in italics. None of it is verifiable: the contractor picks the reviews, formats them, and decides which ones disappear. You have no way of knowing what was removed.

Search engines treat those ratings for what they are. Review structured data published by a business about itself is no longer used to show stars in results — it is ignored precisely because nobody can check it. This site emits none, and that is deliberate.

I would rather give you something you can judge on the evidence.

## What you can look at right now

- **Delivered work** — Projects actually put into production, described by their technical constraint and the solution chosen. No client names, but the detail of what was built. ([/realisations](/realisations))
- **Technical guides** — Procedures written from real breakdowns. It is the best available indicator: nobody writes a diagnostic method for a problem they have never handled. ([/guides](/guides))
- **Faults covered** — Each page describes a symptom, its possible causes and how to tell them apart. Compare them against what you see on your own site. ([/problemes](/problemes))
- **Pricing** — Orders of magnitude stated upfront, rather than a quote you have nothing to compare against. ([/tarifs](/tarifs))

## How to check a developer before hiring them

These questions apply to me as much as to any technical contractor. They cost five minutes and save difficult months.

Ask who will write the code. If the person answering is not the person doing the work, ask to speak to the one who is. Many projects go wrong exactly there.

Ask what happens if it breaks in production. An honest answer describes a rollback procedure, not a promise that it will not break.

Ask who owns the code. Get the answer in writing. A module built for you should stay yours, with its sources.

Ask what is not included. A contractor who cannot say no has not thought about scope.

Ask one precise technical question about your own problem. An answer that describes the mechanism, rather than one that reassures, tells you more than ten testimonials.

## On named references

> I can pass on references from clients who agreed to be contacted, on request and at the point of committing to a project. I do not publish them here: their contact details are not mine to publish, and a useful reference is someone who agreed to be called about your particular project.

## FAQ

### Do you have public reviews anywhere?

My work started on freelance marketplaces, where client feedback is public and hosted by the platform, not by me. That is the only place a review about me carries any weight as evidence, precisely because I can neither write it nor remove it. Ask me for the link and I will send it.

### Why not simply copy those reviews onto this page?

Because copying destroys what made them valuable. A review copied by the person it concerns becomes, again, a text chosen by them. I would rather send you straight to the source.

### How can I tell whether you have handled a problem like mine?

Search your symptom on this site. The fault pages describe concrete causes — a file name, a constant, the precise behaviour of a setting. If your case is not there, write to me describing it: I will tell you whether it is within my scope, including when it is not.

### Do you turn work down?

Yes, regularly. Projects that need a team, projects built on a technology I do not practise, and projects whose stated budget does not allow the work to be done properly. Saying so upfront costs everyone less than discovering it halfway through.